Unit testing is essential in order to ensure that your code does what it’s supposed to do.

But, as much as Typemock is a firm believer in unit testing, well, let’s be honest — it’s not fun.

As our CEO recently put it in Dr. Dobbs, “Unit testing is like staying healthy,” argues Lopian. “Staying healthy requires best practices such as eating right and working out. Similarly, development teams need the right practices in order to innovate faster. Just as it’s hard to start working out, many find it’s hard to unit test and thus stop — despite its well-known benefits”

But unit testing frameworks have many problems.

Some of them include:

1. Lack of Automation – Yes, you can write manual tests and do everything manually. You can also code in Notepad or another text editor. For some, that’s fine – witness the text editor wars in Linux – but others prefer a robust IDE and toolkit. Automatic unit testing saves time, allows for more robust testing,  and allows for tests to be run repeatedly. But even many automatic unit testing frameworks, like xUnit, or mocking-only frameworks don’t let you test much of your code unless you go 100% by the book with excellent design. Most of us simply don’t have code that can be adequately tested by even the most robust open-source frameworks, leaving us (and our business or product) vulnerable to bugs and technical debt.

2. Focus on test instead of code – The goal is working code, delivered on time. But, too often we forget this, focusing on our tests. But, this allows a disconnect between our test and our code. When a test fails, what does that mean for my code? When it passes, how do I translate that into working software?

Frequently, while we know that a test failed, we don’t always know where the error is. This makes it harder to achieve our goal – getting code out in time that just works.

3. Takes too much time – In our high-stakes development environment, frequently understaffed and overloaded, every second counts. Sometimes, we’re also tempted to shortcut now and save time up front – of course we’ll pay for that later but later is abstract when your boss is breathing down your throat. And, yes, even when you have the luxury of doing TDD by the book on greenfield code, it still takes time up front (of course it will save you time overall, but when the release is due, try telling that to your boss).

Currently, most unit testing frameworks run your entire code every time you make a minor change. If you’ made a minor change, you still need to rebuild your code from scratch. That’s time that you just don’t have when your code is overdue. Each change takes time and seconds turn into minutes and hours.

Frameworks need autocomplete – shaving time – and to just run the code that changed.

4. Weak mocking – Require TDD and good design first – can’t deal with legacy code – Simple greenfield code is a nice fantasy but it’s not most projects. What is needed is a framework that can mock complex legacy code, privates, statics, etc. Most frameworks don’t offer powerful mocking or the ability to test legacy code, new code, or even unwritten code.

5. Coverage – Too many frameworks don’t let you know what’s covered and what’s not. Yes, as Uncle Bob said, coverage is not the most important or only metric and 100% code coverage may not always be the ideal.

But, too often, we don’t know what code is covered and what code is insecure.

Leave a comment – what are some things you find lacking with unit testing frameworks. Feel free to tweet as well using hashtag #tddfail

It’s time for a change.

Luckily, change is coming.

Stay tuned.

Can’t wait? Discover unit testing tools and practices this Wednesday and enter the raffle to win an Isolator license.

Want more webinars? Sign up!

Typemock is hosting a webinar about how to test dependencies and legacy code. The webinar will be on Wednesday February 8 at 8:30 PM (20:30) India Standard Time.

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 unit tests to test dependencies and legacy code.

Learn:

• Why you are writing legacy code

• Hand rolled mocks

• Mocking frameworks

• What makes a good unit test

This webinar is intended for .NET developers interested in automated unit testing who want to learn how to develop better code.

You can also win a Typemock Isolator license or t-shirt. You must attend for the chance to win

To sign up: http://www.typemock.com/unit-testing-dependencies-and-legacy-code

Want a sneak peek at what’s coming up in our labs?

Want to learn more, stay tuned for upcoming webinars in February.

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!

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:

Which Icon Do You Want?
Leave your thoughts in the comments or in the survey.

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

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.

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

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

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.

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

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

ThoughtWork’s Brett Schuchert spoke yesterday at the Oklahoma City .Net Users’ group about legacy refactoring using Typemock Isolator.

Brett discussed why you might want to refactor and test legacy code, testability,

Legacy Refactoring Using Isolator from Brett L. Schuchert on Vimeo.

This Wednesday, learn how to start unit testing. If you ever wanted to convince your friends, neighbors, or colleagues about the benefits of unit testing or get them started invite them to Wednesday’s webinar

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. Discover why you should start unit testing, and how you can get started with automated tests quickly. Learn:

· 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.

Sign up: http://www.typemock.com/intro-to-ut-0112

When: Wednesday, January 4 at 10:00 AM ET, 15:00 GMT (UK), 20:30 India (IST)

Typemock’s done a lot in 2011 and we have a lot more to do in 2012 to bring you the best unit testing tools for .NET and C++. We have big plans to redefine unit testing to reduce defects in your code, early in the process, and let you deliver high quality innovation.

In the meantime, though, check out these Top 11 articles for 2011.

11. How do you start Unit Testing? Discover the essential steps to begin unit testing!

10. Are you in the Unit Testing Death Spiral of Doom?

9. Use MSTest? Discover how to check exception messages.

8. Are your tests effective? Here are 3 signs that your tests aren’t doing their job.

7. What does Uncle Bob have to say? Listen to Typemock’s interview with him!

6. Life imitates Dilbert. Does your Agile team look like it’s straight out of Dilbert?

5. Developer testing is highly recommended but it’s not just unit testing. Sometimes one type of test is appropriate and sometimes another. What’s the difference between unit testing and integration testing?

4. SharePoint Dev? Join the community. Here are 10 Resources for SharePoint Developers.

3. Agile turned 10. And, like any pre-teen, it has its growing pains. Agile Development is Broken. How can we fix it?

2. On the 12 Days of Christmas, Santa gave me BUGS! What are the 12 bugs of Christmas?

1. And, of course, our most popular post answers the most important question: why unit testing. Discover 10 Reasons to Write Unit Tests

What do you want to see in 2012?

Start 2012 with better unit testing — join our webinars. Sign up for our first webinar for 2012, Introduction to Unit Testing, next Wednesday, January 4.

The following is a guest post from Ignacio Raffa, a student in Argentina, participating in Microsoft’s worldwide competition for students, the Imagine Cup 2012. He is a Microsoft Student Partner and Windows Phone 7 Developer.

We are developing an open source Windows Phone 7 application that makes extensive use of the device Accelerometer.

To make a proper use of the Accelerometer in the application, we implemented an interface to abstract the concrete class (Microsoft.Devices.Sensors.Accelerometer). We have the significant methods and event of that class in the following interface:

1. C#
   
2. public interface IAccelerometerService
   
3. {
   
4. void Start();
   
5. void Dispose();
   
6. void Stop();
   
7. event EventHandler<AccelerometerServiceEventArgs> ReadingChanged;
   
8. }
   
9. The AccelerometerServiceEventArgs is a custom class that we made (prior to using Typemock Isolator) that enables us to “fake” an accelerometer reading.
10. The problem is that, when the real accelerometer fires the original ReadingChanged event, the argument is of type AccelerometerReadingEventArgs (a sealed final class with not overrideable properties).
11. And that is our first introduction to Typemock Isolator. We have easily created a Unit Test faking an instance of the AccelerometerReadingEventArgs class.
12. C#
    
13. [TestMethod]
    
14. [Isolated]
    
15. public void TestAccelerometerMock()
    
16. {
    
17. var accService = new AccelerometerService();
    
18. var eventExec = false;
    
20. accService.Start();
    
21. accService.Stop();
    
22. accService.ReadingChanged += (a, e) =>
    
23. {
    
24. eventExec = true;
    
25. };
    
27. var rm = Isolate.Fake.Instance<AccelerometerReadingEventArgs>(Members.ReturnRecursiveFakes);
    
29. Isolate.WhenCalled(()=>rm.X).WillReturn(1);
    
30. Isolate.WhenCalled(() => rm.Y).WillReturn(1);
    
31. Isolate.WhenCalled(() => rm.Z).WillReturn(1);
    
33. accService.accelerometer_ReadingChanged(accService, rm);
    
34. accService.Dispose();
    
37. Assert.IsTrue(eventExec);
    
38. }
    
39. We are able to fake the values of X, Y and Z properties using Members.ReturnRecursiveFakes property of the Isolate.Fake.Instance constructor.
40. With Typemock Isolator, we have 100% of Code Coeverage for all the classes that we developed, with a little of effort.

     

    Like what you saw? Want to try unit testing in Windows Phone 7, .NET, or C++ with Typemock Isolator. Download it for free.
    

Isolator++ has two ways to return stuff for a method. It has the ReturnVal to return values, and ReturnPtr to return pointers to objects. What about returning a class by value?

Though there’s no API (currently), it’s very easy to do. You use the almighty 10lbs hammer known as DoInstead.

Let’s say you have this method:

bool Person::IsLivingInLA()

{

         Address currentAddress = Address::GetAddress();

         if (strcmp (currentAddress.GetCity(),“Los Angeles”)==0)

         {

                 return true;

         }

         else

                 return false;

}

The GetAddress method returns an Address object by value. How can we return our own object?

Let’s create a helper class with a static method with the same signature of GetAddress:

class TestUtil

{

public:        

static Address ReturnAddress()

         {

                 Address laAddress;

                 laAddress.SetCity( "Los Angeles"); 

                  return laAddress;

         }

};

This class is part of the test project, not the production code. Now, in the test, we’ll fake the static method GetAddress, by calling the ReturnAddress method instead.

TEST_F(PersonTests, IsLivingInLA_AddressIsLA_ReturnsTrue)

{

         Person person;

         TestUtil testUtil;

         // Fake the static method by calling the other method instead

         FAKE_STATICS<Address>();

         WHEN_CALLED(Address::GetAddress()).

                 DoStaticOrGlobalInstead(TestUtil::ReturnAddress, NULL);

         ASSERT_TRUE(person.IsLivingInLA());

         ISOLATOR_CLEANUP();

}

Using the DoStaticOrGlobalInstead, I pass the static method replacement, and a NULL value (which can be a context if needed, but not needed in this case).

Remember that another option, for calling DoInstead on a member function, you’ll use the call the DoMemberFunctionInstead method instead. That’s because it needs the same signature.

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. Discover why you should start unit testing, and how you can get started with automated tests quickly.

Learn:

• 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.

For the first bug of Christmas, my manager said to me

See if they can do it again.

For the second bug of Christmas, my manager said to me

Ask them how they did it and
See if they can do it again.

For the third bug of Christmas, my manager said to me

Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the fourth bug of Christmas, my manager said to me

Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the fifth bug of Christmas, my manager said to me

Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the sixth bug of Christmas, my manager said to me

Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the seventh bug of Christmas, my manager said to me

Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the eighth bug of Christmas, my manager said to me

Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the ninth bug of Christmas, my manager said to me

Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the tenth bug of Christmas, my manager said to me

Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the eleventh bug of Christmas, my manager said to me

Say it’s not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the twelfth bug of Christmas, my manager said to me

Tell them it’s a feature
Say it’s not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

By Alam Saeed

Start preventing bugs – download The Art of Unit Testing

Typemock would like to wish everyone Happy Holidays free of bug free code!

During this long holiday weekend or if you’re off work all next week, why not spend some time improving your skills? Perhaps some pair programming with your family or friends?

Here are some ideas:

1. Download Isolator.NET or Isolator++ (for Windows or Linux) and start unit testing. You can download Isolator for free and your tests will run even after the trial ends.
2. Watch our webinars – We have webinars on any topic that you want, whether fighting legacy code, Agile development, Testing SharePoint or ASP.NET MVC code, or more. Something missing? Leave us a comment.
3. Ask or answer a question on the forum. We promise, we’ll be around!
4. Read The Art of Unit Testing. You can get a free chapter here.