Should I go back on what I have in my project and write some tests for it, or just finish the project?
You’ve worked long and hard on your projects only to realize that you didn’t write any tests. You’ve read how important tests are. You probably also know this is a best practice, but it’s so much more work. Even worse, what if the tests show you that there are problems. Then you’ll have to work even more to fix them!
The truth is your project isn’t done. Every software product has bugs – you just haven’t found them yet. Of course, you want to do a good job. You want to show people you know the basics. You want people to know you are ready for the next step. But you know, deep down, the whole house of cards will collapse.
You’ll be exposed as a fraud who didn’t bother to test your work. No employer will touch you. You’ll end up living in cardboard box, down by the river, subsisting on a diet of government cheese.
You want tests. You want a lot of tests that give you confidence that when you make a change you’re not breaking things. You want to run your tests whenever you like. You want continuous integration to run those tests whenever you commit a change. You want the world to see you understand how to make safe changes.
The fix: write ONE test first.
You don’t have to blanket the project with tests all at once. In fact, if you try that, you’ll fail. You’ll lose motivation when you realize just how many tests you should create.
You need to create a momentum of success first. You need to have a small, solid win. From there you’ll pick up steam and get more tests in place.
- Find your unit test framework and install it.
- Find the part of your project that is the easiest to test.
- Look for code where you have little or no dependencies. Hint: If it touches a network or file system, keep looking.
- Find functionality where you can isolate a function or class method. Hint: If it takes setting up helper objects then keep digging into the helper objects.
- Create a test file anywhere. Don’t worry about the “right” place to put it.
- Run the test. Yes, it will fail.
- Write one test in a way that you know it will fail. For example, if you are testing a method that should return a number, have the test expect a string.
- Fix the test so it passes. Hint: this might take more than one try. That’s fine!
- When the test passes, commit that test.
- Take a break. Enjoy this feeling!
That’s it. That’s how you get started. Next step is to keep adding tests, one at a time.
If you want to see a detailed example of adding tests, check out