T stands for testing. Understand it first. Chapter 1 — Prologue
Solution for problems on unit testing and TDD.
Have you ever struggled with your unit tests? Have you failed on TDD? Have you been asking yourself why your tests are so coupled with the production? Have you been wondering where is the promised refactoring?
If there is at least one yes, then keep reading. In this series I am going to resolve most of the misconceptions about unit testing and TDD.
Testing particularly in form of TDD is one of the core skills of good software developer. That is why everyone at some point takes attempts to comprehend it. Unfortunately most of available articles don’t represent any practical value. They are a blend of overheard sentences without logical explanation. Thus to sort it out we will begin with the basics concepts to step by step build our understanding.
Testing software — process of confirmation if the software does what it should by satisfying business requirements
Automated test — a piece of code verifying correctness of another piece of software leading to approval or rejection
Why are we testing ?
The greatest problem which the software development has to solve is continuous struggle with complexity. Complexity coming from a domain problem of a business which it works in. Counteracting to that is applying design patterns and suitable architecture. Both of these practices allow us to divide complicated issue into small ones. Another element leading to clarification are tests, which guerantee correctness against expected behaviour of the software. Thereby reasons towards testing are…
- protection of functionalities against incidental changes
- more precise and quick discovering bugs
- creating live documentation of API usage
- gaining confidence about a quality of our code
When we test, we always need to remember why we are doing it.
Never create a test just for testing itself.
Who is the receiver of our tests?
Thanks to “Clean code” written by Uncle Bob or “Refactoring” by Martin Fowler there are more and more developers who make efforts in clarity of their code.
Clean code is a vast term including bundling and nomenclature. Just small improvements in these areas allow to comprehend previously unclear software. There is one thought behind it. The software should be readable for us and other programmers, but we have a huge tendency to forget about it during our testing. Nevertheless tests are an integral part of the source code of our applications and should be treated as professionally as production.
How we divide tests in terms of refactorization ?
The common characteristic of all tests, independently of a testing framework or their scope, is knowledge level about implementation details. Based on that factor tests’ nature spreads between two widely known terms.
White-box testing is a method of software testing, that tests internal structures or workings of an application
Black-box testing is a method of software testing, that examines the functionality of an application without peering into its internal structures or workings
As you may guess, as more of your tests validate a behaviour of a software and less the way it works, the more of your code become elastic and prone to refactor. Be aware, the reversed sentence is also true.
To sum up, now we are aware of how relevant tests are, who is the receiver of them and why some approaches can help us in refactoring. In the next Chapter 2 of this series we will talk about misconceptions on unit testing and where is the right place for tests in a software architecture.
Cheers
