Between handling response issues, we’ve continued our NUnit exploration.
From what I’ve been reading, it appears that using NUnit without the intention of TDD is like using Visual Studio without enabling Intellisense. Why bother?
I started by reading a few articles, such as Getting started with TDD, by Steve Smith. I also read a good one by Roy Osherove, and he states in his Test-driven development with NUnit – Introduction article, there are three bulletpoints for doing TDD:
- Make a test that fails
- Make it work
- For every new feature, go to step 1
Now, that seems rather simple, but the hard part is figuring out what tests to write, and if you’re testing existing code, should you refactor it in order to enable proper testability.
The concept that seems to be hardest for people starting out in TDD to grasp is the whole concept of writing a test that fails even before attempting to write the code that implements the feature being tested. But if you think about it, it’s a pretty common iterative approach to things.
The first example in Roy’s article shows that you do this by trying to instantiate an object from an as-of-yet non-existent class. You can’t get much more basic than this. That’s an easy one to get to pass, and it’s a bit of a high getting that test to turn green. Now you feel like you’re on your way.
Roy’s article is a great intro, but the main goal I’m trying to accomplish is to decide HOW to introduce NUnit and TDD to a development team, so I’m continuing to research how other teams have done this.
We’ve answered our first two questions from the prior article , and decided not to learn by incorporating tests into our existing systems, mainly due to the comment made in my previous article that we need to assume that current systems are “clean”.
Due to scheduling conflicts, we also answered question 4 (should we have the team work together on a single system so we can all learn together, etc.). We’re experimenting on our own with samples that come with NUnit, plus our own small examples. As we work on future projects, we’ll build on that by generating tests for new code, and creating tests for modified code. We also recognize that refactoring will probably be in order to make existing code more testable, so we have to be mindful of including this into our estimates. Convincing management shouldn’t be too difficult, since they already feel the pain of too many bugs getting into QA, and are realizing the up-front time investment is worth it.
We’re still discussing question 3, the introduction of mocking. We’re leaning towards building our own mock objects on an as-needed basis at first, and we’ll look at third party mocking tools later on.
We’ve also taken a look at TestDriven.net , which provides some basic integration into Visual Studio. The best part of this tool that we’ve seen so far is the included nCover utility, which helps us to see what code we may have missed writing tests for. The jury is still out for us on the entire TestDriven.net tool, since nCover is available separately, but some people swear by the whole package.
Well, on with my best practices investigation for introducing NUnit and TDD…
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
Hi Mark…
I have read your post and it is familiar to me.
I began using automated tests and TDD few years ago.
Actually I was first in the team that began using automated tests.
I wrote in my blog about how did it work.
I think it will be interesting to you to read
http://experienceuser.blogspot.com/
There is more in
http://blog.typemock.com/search/label/beginners
Waiting for comments (if you wish)
Menahem Cohen
Mark,
Typemock is a good tool for generating tests for existing code. You do not need to refactor existing code to use Typemock. The drawback is that Typemock costs money to buy. The Visual Studio 2008 IDE has unit testing and code coverage built into the product. It makes it easier for a development team to implement testing. You can write a test first but you can also use Visual studio to generate a test method by right-clicking on a method you just wrote and then select generate unit test. As far as knowing which tests to write first, you can determine these tests from your use cases on a new project or for a new enhancement.
Thanks, Menahem. I started reading your articles. By the way, your blog home page is impossible to read. For some reason, the font is dark blue on brown, and unreadable without selecting the text. But the individual articles are perfectly readable. I think it’s just a home page issue.
Michael, Typemock looks affordable, so I’m going to look into it. But would you recommend this over something like RhinoMock, which I’ve heard mentioned more? I’ll do some digging myself.
We decided to skip the built-in unit testing for a few reasons. One was the fact that NUnit is free anyway, and extremely popular, another was because a few people in our department are already experienced with NUnit, and we could pick their brains, and finally, we use ReSharper, which we just realized has great VS integration for NUnit. Also, I’ve read about some serious frustrations people have had with the built-in version. There does seem to be some cool features for the built-in tool, though, and I will experiment with it more.
Thanks.
If you have NUnit then that should be fine. The built-in testing in Visual Studio is good for developers new to Unit testing and they may find it easier to learn and do testing if it is already part of Visual Studio. Also, it may be an easier sell if you tell developers that it is from Microsoft and built into to Visual Studio. I have never used TypeMock but have heard that it can be very powerful and possibly too powerful if not used properly. What I mean is that a developer can get away with writing lousy code that can still be tested by Typemock. I prefer Rhino Mocks because it is free and it allows you to do state based testing and behavior based testing. State based testing is simply using assert statements on variables and function return results whereas behavior state testing allows you to test that certain objects/methods are called in the correct sequence based on a set of preconditions. And don’t forget NMock is out there and is free too. NMock has a shorter learning curve than Rhino Mocks and the documentation and tutorials for NMock are easier to understand than Rhino Mocks.