In my previous blog I answered the question if you should do test automation. Well that answer was clear: YOU SHOULD! But then the next questions pop-up: “Where to start?”, “How?”
The first thing you need is knowledge about test automating. When you leave school or never invested time in learning how then start there. Attend a TDD training, watch videos, read blogs invest time to learn how unit testing works. But that’s not all, also invest time in stuff like clean coding and design patterns. At the end of this blog I will put in some links to books to read .
So after you gained some knowledge the next step is to embed it in your way of working. Because thinking test first is a pattern you have to adapt. This doesn’t change overnight. It has to become your natural way of thinking and working. So at least start with creating unit tests. From there get familiar with it and then you will experience that writing them from the start works better.
But what if you have an existing code base without that much tests? Where to start then? Stopping the work and starting to write tests for all the code isn’t likely to happen. Best way is to look for the most important parts. Which parts of the code have the most important/highest risk code? Where is that important calculation? What part can damage your reputation? Focus on those areas first. Determine how you can test this code. The TDD training or books can also help you with knowning where and how to start. You could also agree that you spend a bit more time working on new functionality. While creating the new functionality you write unit tests for the new and the existing code you need. This way you can slowly increase your unit test base.
If possible, create unit tests to validate the functionality of the problem/high risk areas. Build it up, so first create tests that validate the current behavior. Then, when you have this safety net in place, you are able to refactor the code. Using the tests you’ve written, you can validate if the behavior is still the same. This way you are able to harden the codebase and apply the SOLID coding practices.
When the code has a lot of dependencies or large methods or classes and unit testing is hard then look at integration tests or even UI tests to begin with. Reason why I prefer unit tests is the speed and maintainability of unit tests. If you have a look at the testing pyramid by Mike Cohn (also look at the books below). The base is unit testing for a reason. They are cheap, fast and easy to maintain (FIRST). The higher you come in the pyramid the more time it takes to write, maintain and execute the tests.
Integration tests are often written in the same language as unit tests. These tests are similar to unit tests but they cover a greater part of your code. They go beyond the boundaries of the application by calling a database, a web service or some other API.
Looking at UI tests this is a different type of test in most cases. You are testing functionality through the eyes of the user. So these tests have a more functional nature, which make them better suitable for a BDD / Specification by example way of working. They are useful and probably are necessary but be careful because they take a lot of time to create, maintain and run.
So start gaining knowledge and then go-on and start writing tests as part of your programming habits.
Interesting books to read:
- Extreme Programming: Embrace Change – Kent Beck
- Test Driven Development by Example – Kent Beck
- Test-Driven – Lasse Koskela
- Clean Code: A Handbook on Agile Software Craftsmanship – Robert C. Martin
- Refactoring: Improving the design of existing code – Martin Fowler
- Growing Object-Oriented Software Guided by Tests – Freeman & Pryce
- Code Complete: A Practical Handbook of Software Construction – Steve McConnell
- Specification by Example: How Successful Teams Deliver the Right Software – Gojko Adzic
- Refactoring to Patterns – Joshua Kerievsky
- Working effectively with legacy code – Michael Feathers
- Agile Principles, Patterns and practices – Robert C Martin
- Head First Object Oriented Analysis & Design -Brett Mclaughlin Gary Pollice
- Head First Design Patterns – Eric Freeman Elisabeth Robson
Trainings to follow:
- Certified Agile Test Driven Development – click here
- Automating User Interface Acceptance Tests – click here
Curious what we can do to help you? Check our website