Continue reading »]]> It’s that time of year when the US president gives the annual State of the Union. Since Mr. Obama did not mention unit testing, (I suspect because of homeland security issues) I thought I’d give you my view of where unit testing is in the beginning of 2012.

• Unit testing and TDD are getting traction. More people understand the value, and more developers see that testing is part of what makes them professional.
• Unit testing has a wide acceptance across technologies. Developers who unit test, do it across languages.
• More and more, we regard unit testing as a skill, rather than a development methodology. As any skill it is learned, experienced, improved and mastered. Some people go all the way, some people start and turn back, never to return.
• Mastering unit testing requires discipline. Discipline begets professionalism. Those things go together, and why you’ll find both traits in successful developers.
• A lot more people do not unit test than those who do. That’s because unit testing is still hard. The tools are mostly there (depending on the technology and language). Successful developers do not just master tools, but also apply their experience on how to write tests, organize them and maintain them. This is not taught anywhere, and most developers don’t have the mentors, drive or discipline for the long haul.
• In many organizations that unit test, it’s not really wide spread. A few teams do it, the rest don’t. In order to do an organizational change, you’ll need the skilled people in place to drive the rest of the teams. Since there aren’t many of those around, the organization adoption is very slow.

So what’s next?

The slow adoption rate will change based on two things: better tools that make it easier to test and fix bugs, and the availability of many people to drive teams toward adoption. Typemock will drive the first part (I’ve already alluded to new features in Isolator V7 and that’s just the beginning) but the community needs to do the evangelizing and education that will get more people into the unit testing circle. With more people around we can turn the trickle into a torrent.

And then nobody will have bugs! But I’ll leave that to next year’s State of the Union.

Beg to differ? Write down you’re assessments and predictions in the comments!

Continue reading »]]> Want to help Typemock and the unit testing community.

Contribute to Typemock’s latest project.

We’re currently developing a brand new way to do unit testing – it’s a whole new perspective.

I can’t tell you what it’s going to do but sign up for our upcoming webinars to learn more.

We need you to choose. Which icon do you want to see?

Version A:

Version B:

Leave your thoughts in the comments or in the survey.

Continue reading »]]> By Gil Zilberfeld, Product Manager, Typemock, February 1, 2012

When: 10:00 AM ET, 3:00 PM UK, 5:00 PM Israel – Click here to see when the webinar is in your time zone.

Software testing isn’t just a task for QA. In order to prevent bugs and release quality code to market, you also need developer testing, including unit testing.

Learn the difference between unit tests, integration tests, manual tests and acceptance tests.

Learn:

• QA vs. Developer Testing
• Benefits of unit testing
• xUnit Frameworks
• The difference between unit testing and test driven development (TDD).

Join this webinar to learn what you need to know in order to start testing today. You may also have a chance to win an Isolator license – but only if you attend.

Click here to sign up

Continue reading »]]> Easy question, right? You DEBUG.

Not so fast, my friend. Actually, if you think about it, debugging is not so fast. Pretty slow, really. I’d rather do as quickly as possible.

Let’s get back to the question: A test (or three) failed, because you’ve changed the production code. How do you fix it?

Tests’ primary role is to notify you that something’s broken. The have a secondary role, which we don’t really think about often: help us fix that bug as quickly as possible.

So what do we do when a test fails?

Naturally, we look at the name of the test. This is the first clue. And why you shouldn’t name your test “Test33”. The test’s name should explain what the scenario actually tested and the expected result.

The next step would be thinking: What code did I touch? (Or, in other words: What shouldn’t have I touched?). If we run our tests regularly, like every few minutes, we’d probably know. If it’s more like a few hours or days, we won’t.

But that’s not all.

We also look around for tests in the vicinity of the tests that failed. Why are those tests passing, while others are failing? What different scenarios do they cover?

We think about all three, and try to make sense of what just happened. We want to fix the bug as quickly as possible.

So wouldn’t it be great to have something like this pop up automatically on the production code that you’ve recently changed, when you build your code?

Yes it would.

And it’s coming soon in Isolator V7. Stay tuned.

Continue reading »]]> Everybody has legacy code. How do you apply unit testing to existing code? Code that wasn’t meant to testing.
This is a hardcore session, where we take an open source application and add tests to it. In the process, we’ll refactor the code, discuss readability, and where to even begin.

This is an intensive demonstration of automated testing hard-core legacy code. If you are a legacy ninja, check it out.

Everyone is welcome but it is most appropriate for people with a background in unit testing and medium to advanced skills. If you’re a unit testing ninja, this webinar is for you!

Sign Up and You’ll Also Get a Sneak Preview of the Newest Perspective on Unit Testing, Cooking Up in Typemock’s Labs

(Oh, and you may win an Isolator license or Typemock t-shirt too).

When: Wednesday, January 25 at 10:00 AM US Eastern Time, 3:00 PM in the UK

Click here to sign up: http://www.typemock.com/testing-untestable-code-january

Continue reading »]]> When you start unit testing, you’re going to bump into problems, especially when you already have an existing code base. But we’ve created Typemock Isolator just for that. Discover how to use Typemock Isolator effectively for you and your team.

In this webinar we’ll show you how to tackle day-to-day problems you’ll find, and how to easily solve them with Typemock Isolator.

In this webinar, learn:

• Handling live objects
• Dealing with objects
• Testing private functions
• Verifying calls without state
• Handling ref and out parameters

You will also see a sneak preview of the latest coming out of Typemock’s labs

WHEN: Wednesday, January 18 at 10:00 AM ET, 3:00 PM GMT

Sign up: https://www2.gotomeeting.com/register/809826250

Continue reading »]]> I’ve recently read Phil Haack’s post about “structuring unit tests”. And then Ayende’s response. I’ve also went over the comments on both posts, and clearly, most were in favor of having some kind of method to structure or organize test code.

Who’s right?

I used to work with someone who was very VERY organized. His Outlook had dozens of folders and sub-folders. He know exactly where to file each email, and consequently, where to find each email. If I were looking for something and couldn’t find it,  I’d turn to him, and he would find it rather quickly because everything was filed according to a “system”.

Mind you, mostly I find email. I keep all my past emails in one folder called “backlog” and use the search box.

Who’s system is more organized? My friend’s, obviously.

Which one is more effective? Now that’s a different story. The search box finds things much quicker. There’s also a penalty in the filing system. For each email, my friend needs to think where it belongs. What if it deserves to be in two places? The filing itself is costing him time.

See the resemblance?

Reading all the comments that favor the structuring method, or any method, and stating its not much work and effective, made me think: Have these people lost their mind? Have they lost sight of what’s really important?

Tests have a primary goal: to tell us we’ve broken something. Once I write a test, I hope and pray I’ll never ever see it again. Because if I do, something’s broken and I’ll need to fix it. Otherwise, this test vanishes between the other hundreds or thousands of tests. Which is fine by me. If the test fails, my test runner will get me there in two clicks.

It seems that along the way, we’ve placed too much respect upon our tests. No wonder, since we’ve crowned TDD as a “design method”. Obviously tests are not mere code, they are a design tool. and therefore should be treated even better than production code.

What’s important is working production code.

Tests are the most effective tools to get to working code. But let’s put things in perspective: they are just that – tools.

And the upcoming Typemock Isolator V7  is all about a new perspective.

Stay tuned.

Continue reading »]]>

According to Forrester Research, bringing software testing into the development role (including unit testing) will lower defects and increase code quality. They also noted that even teams that haven’t fully integrated Agile practices can still benefit from developer testing.

According to Forrester, finding bugs early saves time and money later. By engaging in development testing, the initial investment will be paid off with faster releases at a higher quality, with less technical debt.

According to the report, one of the barriers of unit testing has been existing legacy code, which results in slower time-to-market and results in lower code quality. This is, of course, a problem that Typemock Isolator can solve.

Forrester Research recommends educating developers on the importance of developer testing and automating their testing, in order to increase efficiency and save time.

Download the Full Report Here

Continue reading »]]> When: Wednesday, January 11 at 10:00 AM ET, 15:00 GMT (UK), 20:30 PM IST (India)

You may have already started unit testing or at least understand the basics. But there’s one large obstacle that stands in your way: dependencies. Most code was not written to be easy to test. How can you test dependencies? Join this webinar and learn different methods and tools that help create real unit tests.

Learn:

• Why you are writing legacy code
• Hand rolled mocks
• Mocking frameworks
• What makes a good unit test

You may also win a free Isolator license including 1 license exclusively available via Twitter.

Limited seats are still available – Sign Up Now: http://www.typemock.com/test-legacy-code-january