Motley says: "Unit tests take too long to execute, so don't bother"

Summary

Motley: Unit tests take too long to execute. I'm not going to bother.

Maven: Unit tests need to run quickly - you need to execute them frequently. Mock objects can help.

______________________________

[Context: Motley has been writing unit tests for a couple of days, but is not sold on developers writing test code]

Motley: I've been trying this unit testing thing for a couple of days now but I can't really say I like it. I developed this little executable to run my tests and that took time. You stated that I should run them regularly, but they just take too long to run.

Maven: Whoa - hold on a second. Let's address these things in turn. You're coding using C#, right?

Motley: Yeah. I wouldn't have it any other way.

Maven: Well, it just so happens there are some existing unit test frameworks out there that you should leverage.

Motley: Framework? For what? I just wrote a little executable to run my tests.

Maven: A good C# unit test framework like Visual Studio 2005 or NUnit can do some work for you. They quickly run tests, provide some good visual feedback, tell you the details about any failures, and make it dead simple to write new tests. You definitely need to be using a unit test framework!

Motley: I didn't even know you could do that with Visual Studio - might be worth a try. BUT, these tests just take too long to run so I'm not even sure it's worth the effort.

Maven: There are certain rules of unit testing that you need to follow. First, tests need to run quickly! If they don't run quickly, like in the order of seconds, developers won't run them and they get stale and unused.

Motley: But my tests have to run over a network to talk to a web service that has a computational intensive algorithm. It takes time. Nothing I can do.

Maven: You're testing your own code, right? Not the web service on the other end?

Motley: Yeah, so?

Maven: Replace the web service! You can create a stub or a mock object to take the place of the web service. The stub simply simulates the web service and returns a result for your test immediately. No network or long computation required.

Motley: That's cheating, dude! I'm not really testing the system then. It's fake!

Maven: Ahhhh, but we're unit testing here. The keyword is unit. You are testing your code that interacts with the web service, not doing a full integration test from end-to-end. Unit tests cover small, isolated chunks of code and simply validate the implementation of those small chunks.

Motley: But I still have to test the web service results!

Maven: Yes, but the web service will have its own set of unit tests.  And just for the record, you also want your unit tests to:

○ Leave the system in the same state you found it (e.g. don't leave files sitting around that your test created)

○ Test very small chunks and not combine test cases (helps you quickly pinpoint the problem code)

○ Cover positive cases (the main logic) as well as negative logic (error cases)

○ Not be dependent on each other (don't expect unit tests to run in a particular order)

Motley: Okay, I'll try your suggestions. I guess if I want to replace components with stubs, I need to make sure they have well-defined interfaces so I can plug and play different implementations.

Maven: You are a smart man, Mot, a smart man.

______________________________

Maven's Pointer: Check out the infrastructure components that already exist to help with unit testing. Free tools for managed code include NUnit (https://www.nunit.org/)  as a test framework and NMock (https://nmock.org/) for creating mock objects.

Maven's Resources: Pragmatic Unit Testing in C# with Nunit, by Andy Hunt and Dave Thomas, Pragmatic Bookshelf, ISBN: 0977616673, 2007.

Temporary Link: Technorati Profile