My goal for this quarter was to learn about unit testing in development. You see, in Bootcamp, we only touched on testing for one afternoon – and that was about Test Driven Development (TDD). When I started my first development job, there was no focus on unit testing. It wasn’t until I started my latest position in development that there was much focus on testing.
I hear similar stories from other developers I know. Some companies have a strong focus on unit testing, while others rely on the Quality Assurance process.
So I thought I would write a post about how my views on unit testing have changed, and why I now see it as an essential part of a developer’s work process.
What are the unit tests? Unit tests are void methods written to demonstrate if other sections of your code do what is expected. Think of it as if you are a student and you’ve just completed a test. Your teacher has the answer sheet. So the only way you’ll find out how many questions you got correct you have to hand your completed quiz to your teacher and they will mark it and pass it back to you, usually with a cross or a tick depending on if the answer you gave matched what the answer is on the answer sheet.
However, you have to remember this is only a quiz, not an essay. Therefore we want to focus on testing small sections of our code and ensuring that each unit does as expected.
When should you write unit tests? When you start writing your unit tests varies depending on the type of work. For example, if you start a new project or a new piece of work, you could start writing your unit tests before you start writing the code. Writing the tests this way is called Test Driven Development. The tests direct how you will write the code. However, if you do not like doing this or are working on legacy code that does not already have unit tests, you will write the tests based on the code. Wrapping your code in tests is known as putting your code in a test harness.
Am I going to destroy the universe if I don’t include unit tests in my work? No, is the simple answer. Like I mentioned before, there are situations where you will work with people who do not use unit testing. However, by writing unit tests, you can be more confident in the code you write and any changes you make. If you are refactoring code, as long as the unit tests are still passing, you can be sure that your code is still functioning as expected.
Now I’ve gotten that out of the way; you can guess what my theme for this week’s blog posts is: Yes, unit testing!
Come back tomorrow, and I’ll introduce you to writing your first unit test.