I wrote this post as a motivation for anybody trying to start with writing tests for their code but feels some kind of resistance or fear from doing the first steps. Both of these feelings are natural and reasonable. Doing testing right is not an easy task. The whole testing thing with all its terminology, tools, styles, philosophies, metrics etc. can feel a bit overwhelming, at first. And it really is. The good news is, though, that you don’t need to digest it all at once.
Start small
As with every big problem there is a way to break it down and start with the small pieces first. At the end, every test is just a piece of code that exercises some other code. Do you feel any big concept in that? I’m sure not. So, how about just starting to write some little piece of code that exercises some other code you wrote? You do it all the time anyway, don’t you?
You don’t need to start with any “big” concepts such as TDD (test-first driven development) from the beginning. If you really want to give testing a shot and are lost (as I was when I started with testing just few months ago), start doing it in small unobtrusive steps. Next time you start working on some application (or just a new feature in an existing one) do the first step as usual - think about the feature you are about to code, code it and try to run it. Write as little code as possible, though. The aim is to have some solid piece of ground to stand on. When done, you can start to cover the code you just wrote with tests. I know, it’s quite difficult to decide what exactly to do when you stare at a blank test file, at first. But don’t fear. Just grab the first testing-belt (whatever testing library you’ll find in your closet) that suits you (which means, the first one you have or you think you can have some clue about) and throw the first little thing you think can have some effect on your code. Try to assert something or just grab something randomly if you think there’s no other way out and fire. It may work. Just do something! You’ll quickly learn to distinguish between good and wrong weapons for particular situations. You’ll be surprised how quickly these tools make sense when you use them actively.
Other great opportunity for doing experiments with testing is when you have some considerable piece of code already written - it may be some old nasty application, running for years - and some trouble strikes. You know it should work, but it doesn’t. So, you find the troublemaker and are about to fix it. Why not fill in some tests now to make sure you have that delicate piece of code under control? It’ll make you more confident, at least.
Okay, but where to start anyway?
As for the question which kind of test you should write first (unit, functional, integration or whatever other kinds there are), the same rule applies - do whatever you think you have or can have some clue about. First, try to write for example some unit test. If you fail, just try something else. Maybe it’s best for you to start with some kind of general acceptance tests, like “when I call this url in the browser, I should see my name on the page somewhere.” There are tools and test-belts (eg. webrat for Ruby/Rails) you can use for writing this kind of tests, too. Just choose what makes sense to you. Any piece of code that tests something your application should do, is valuable and will rise your self-confidence about what you have done as well as your positive feelings about testing.
Are tests just other stuff I have to write?
You may also think that you are going to do just “one more thing” on the top of all the other things you already do when you code. That is true. On the other hand, testing, when done properly, should minimize some other unpleasant activities you usually do while coding. After you’ll start doing it, you’ll notice eg. that you don’t switch between your editor and the browser that much anymore. You write tests and run them instantly in the background (automation of testing is usually very easy to set up in current testing frameworks) instead of switching between the windows and hiting F5 all the time (if you’re developing mainly for the web). You’ll find out that you don’t need to dig into your code with a debugger that much, anymore. And if you will need to work with your older code, you will find it much more comprehensible with the test code at hand. Your workflow should improve with testing, not break. Write tests only if it makes your life easier. Otherwise, it won’t make any sense. Tests are for you, the developer, in the first place.
To sum it up …
Start writing tests whenever you have an opportunity to do it (ie. whenever you write some code). Choose any tool that makes sense to you and write any test that you feel could cover at least some tiny behavior of your application (don’t care about the coverage or any other scary terms from the day one). Don’t be afraid about primitive tests and trivial assertions - you’ll get more confidence as your test coverage will grow and you’ll become more and more happier as you’ll notice that you don’t need to hit F5 that often anymore. Think about testing in other positive terms - the better you are at it, the less time you need to spend with activities you don’t like (watching the spinning refresh icon in the browser, debugging) and more with things you love.
December 31, 0:59 2008
