CodeProject
I finally decided to get back into Unit Testing...
I have worked once in the past for a short period of time (only a couple of months) with unit testing, and my experience is good with it. The problem is that where I currently work, my team isn't really into it, and aren't too keen on trying either.
Since I haven't used it in a while, it feels to me as if I lost my unit testing mojo, and need to learn everything from scratch again.
At first, I though the best way to start is to actually write unit tests for projects I already wrote. This isn't TDD at all, but it's still something, and I feel as if I'm getting the "infrastructure" ready for the rest of the process...
Another thing I just thought about doing today was giving a lecture at work to my fellow team mates on unit testing, hoping that they will see the good side to it, and they'll want to know a little more on the subject!
Sometimes the best way to learn is by teaching! :)
I started building a demo project that I will show as part of a presentation I'm working on to go with my lecture. The project is just a simple calculator.
I am gathering all the points I need to discuss on this lecture, but trying to keep it simple and as convincing as possible to people who don't think it's useful or don't know what it is yet. Seems like quite a challenge, but I'm up for it!
So far this is what I got: (these are the points that are going into my presentation)
Let's say we're building a new class as part of a winform that does some calculation. How do we usually go about testing this?
We would press f5 (debug) and play around with the UI a bit to see that everything's working...
Why is this bad?
- We have to do this again and again every time we change a little piece of code since we can't be sure it still works.
- If someone else on the team changes our code, we'll need to run the tests again.
- Someone might change a piece of code, play around with the UI and still not know about special corner-cases we were looking to handle in a specific way.
- Time consuming!
- In this case, it's a winform and might be easy to test manually, but if we're just building a web service for example, I usually see people building these funny "tester" projects that they can send some sample input and see what happens.
Why does writing Unit Tests make life easier?
- By writing unit tests, we are writing code that will check our functionality instead of doing it manually.
- We can run the tests every change we make, and this will be much faster than manually testing.
- If we write the tests properly and cover all the code we wrote, then someone else can change the code around or add some other functionality with the knowledge he didn't screw our code over!
- Just by looking at the unit tests, we can spot the corner-cases we should look out for.
What do we test and what not to test ?
- Test all public methods in a class. If the tests are written good enough, then the private methods will be covered within these tests.
- Make sure you're not writing tests to check the .NET Framework - this means you don't need to go crazy and start writing tests for each .NET method!
- Tests shouldn't need configuration. You should always be able to run the tests immediately. This means you need to avoid having your tests writing out to log files, db, network streams, etc. Instead, create mocks of these interfaces so they don't actually do this during testing.
Well, I feel like I'm new to this as well, so I'm looking for some feedback on these points I have for my presentation so far...
During the presentation, I also want to show the simple demo test project I created, and how to write basic tests for it. I will show common cases when changing code can cause different behavior that might not be spotted at first by manually testing...
Seeya'...
P.S. - Anyone interested in learning more about unit testing should check out these blogs: Ayende & Roy Osherove
