For the last few of months I started digging into the software testing world. I really wanted to learn more about how to create more effective tests, refactor code with more confidence and feel safe about adding new features. However, I felt it is little difficult to dive right in this area, that in my point of view, is underestimated. After some good readings and studies, I decided to start applying this new concepts in my professional projects. The intent of this article is to provide some insights, external material and advice based on what I studied and applied at work so far. TDD is awesome (but it’s not the only way) Everybody loves Test-Driven Development, , right? Just kidding. The fact is that it is very difficult to talk about testing without mentioning TDD. That’s why I gave a try and implemented a new feature and a huge refactor in my professional projects using it. David Heinemeier Hansson I really liked developing using TDD and the results were very satisfactory: the deadline has been met, it works really great with pair programming and no reworking so far. And I felt a lot about the that Kent Beck talks so much about. confidence However, TDD is not the only way to apply tests in your projects. Don’t feel pressured to apply TDD in your work environment just because “that’s what the cool kids are doing”. There is no such thing. The most important part is to add meaningful tests in your project. Don’t worry if you add them before, during or after the code development. Regarding this topic, I strongly recommend the between Kent Beck, Martin Fowler and David Heinemeier Hansson about TDD. It is a very insightful discussion that will probably make you rethink what you know about it. series of conversations It's not clear as night and day We are developers, we love dichotomies. If it’s not , then it is ; if it is not , then it is . That’s how we are. Well, testing is not exactly this way. To start, the term Unit Test varies a lot between authors. When Martin Fowler asked about the definition of Unit Test to Kent Beck, . true false 1 0 he replied that he covers 24 different ones during his training course Despite having a lot of definitions, the Unit Test have three distinct elements, : according to Martin Fowler They are low-level, focusing on a small part of the software system Written by developers, using their own tools Expected to run faster than other kind of tests The test suite speed is also a common point of disagreement. Some developers , but compromising a little the speed; others . praise for more authenticity in their tests praise for a very fast feedback loop The lines that separate the different test types are also a little fuzzy: when adding an actual database running in your tests, even if it runs very fast, does it continue to be a unit test? When developing using TDD, the tests are black box or white box? Are you a tester or a developer? . Kent Beck has a great article about how these dichotomies are volatile in test environment There a lot of fight about terminology and where each type of test ends. My advice is focus in creating meaningful tests, tests that adds value to your project, tests that you can rely on. Don’t worry so much if your tests take 1 minute or 1 second, or where it fits in the test pyramid. Do not test implementation, test behavior As I mentioned earlier, there are several concepts of Unit Test in different sources. One problem is that this can lead us to creating a Unit Test for every new class or function you add in the project. That’s not an issue until you need to refactor the code and finds out that your tests needs to be refactored as well. There is an about the misinterpretations regarding Test-Driven Development. Even if the video is focused in TDD, I recommend watching it because some of the concepts are applicable for other test techniques. Some of the points that helped me a lot writing better tests are: excellent talk from Ian Cooper Do not write test for implementation details Implementation details changes a lot. They can be refactored, removed, moved etc. If you base your tests in statements like “verify that this function was called”, it’s likely that as soon as this part of the production code is updated, your test will break. A new class or function should not trigger a new test It’s not because a new class or function is created that a test to cover it should be created right away. Specially if this new class or function is internal (not visible by another scope of your software or by a client). Creating new tests is great to help build reliable software but creating unnecessary ones makes the code too rigid and awful to refactor. Always ask yourself before adding a new test and don’t be afraid to remove if it is not meaningful in your project. A new behavior should trigger a new test If your software receives a new requirement, it should trigger a new test to cover this new requirement. Try to focus your tests in how your application should behave. For example, if application is a to-do list probably the requirements are “create a new to-do”, “update a existing to-do”, “create an alarm for a to-do” etc. That’s the behaviors you should cover in your tests. Do not test internals The internals of your software (private/protected/internal classes and functions) concerns only the implementation details. These are the ones very likely to be updated during a refactor and you should not test them. Instead, you should have a thin layer (API) that is testable. With this API layer, it’s is possible to test the input and output of the behavior without testing every single internal of your software. Be careful with mocking Mock is a powerful tool for creating doubles in your tests, but it comes with a cost. Usually, the test using a mock needs to knows some of the detail implementation of the . This can be an issue when refactoring your code. System Under Test (SUT) Let’s imagine a very simple scenario: We are developing a feature that selects all the users that have birthday in the current month. We may have basically four classes: contains the business logic Use case – provides a list of all users from a source User repository – filters the user by a given criteria Filter – provides date and time information Calendar provider – Once our SUT is the class we decided to mock the and classes. The first problem here is that the test class needs to know which function inside each class needs to be mocked. And we have a bigger problem now: if any of these classes structure changes, we break our tests. One of the major advantages of having tests in our code base is to ensure that refactoring does not break the working code. But if our test breaks so easily when we simply move an internal class or rename a function, how can we trust them? use case user repository, filter calendar provider During one of the : discussions videos, Kent Beck said Do you mock absolutely everything? My personal practice is: I mock almost nothing. If I can’t figure out how to test efficiently with the real stuff, I find another way of creating a feedback loop for myself. Which leads me to the next point. Mocking is not the only test double We have other types of doubles for using in our tests. In the clarifying article “ ”, Martin Fowler mentions the for each double: , , , and . Mocks Aren’t Stubs Gerard Meszaros definitions Dummy Fake Stub Spy Mocks You can find more information about their definitions in the links above, but the point is: you don’t need to mock everything in your code. Actually, I agree that you can . In my personal experience, I try to use the whenever I can. If it is not possible, I create a representation and my final attempt is to it. simplify the double definitions real implementation fake mock Good tests leads to good design (and vice versa) While developing using TDD, I found myself questioning the software design more often than usual. Simple questions like “how can I test it?” or “if we invert this dependency, will be easier to test it?” help a lot creating a better design. Of course these questions may appear during a development not focused in testing, but in my experience they appear much faster when you put light on it. In the feature development mentioned earlier, we decided to refactor a simple utility class that is extensively used in that scope. The new version of it, developed with testing in mind, created a more flexible, reusable and API-like class in our project. Concepts such as and principles plays really well with testing in mind. It is very difficult to test a code base that does not have a good design: it is hard to replace real implementation for and probably you will have to . Clean Architecture SOLID test doubles rely more in UI tests than Unit tests Testing is hard and it is not a technique that you will master after your first attempt. Give it a try, learn, fail and retry. Final thoughts My feeling is that software test is very underestimated. It is very common to find articles about how-to, new frameworks, new techniques but is not easy to find ones focused on testing. In fact, I worked in several projects where the was the (anti) pattern and there were no attempts to change this scenario. Software Testing Ice-Cream Cone Adding meaningful tests to your code base will make your project more reliable and easier to refactor and introduce new features. Also it will make you grow as developer, giving more tools for better coding. I believe I neglected tests during my first years in software development because we don’t talk enough about this topic. But I also believe that a meaningful test is better than having no tests at all, even if you are not sure about the technique. It all starts with one little green bar in your project ( ). or red if you are using TDD External resources In this article, there are several external resources with more information about each topic mentioned. To facilitate the access, all the links are available below: —  David Heinemeier Hansson TDD is dead. Long live testing. — Martin Fowler Is TDD Dead? — Martin Fowler UnitTest — David Heinemeier Hansson Slow database test fallacy — Destroy All Software via Internet Archive TDD, Straw Men, and Rhetoric — Tim’s Dev Blog Test-Driven Development Violates the Dichotomies of Testing — YouTube Ian Cooper — TDD, Where Did It All Go Wrong — xUnit Patterns SUT — Martin Fowler Mocks Aren’t Stubs — xUnit Patterns Mocks, Fakes, Stubs and Dummies — Stack Overflow What’s the difference between faking, mocking, and stubbing? — Quality Thoughts Testing Pyramids & Ice-Cream Cones — Clean Coder Blog Clean Architecture — Martin Fowler The Practical Test Pyramid — Clean Coder Blog The Cycles of TDD — Clean Coder The SOLID Principles of Software Design —  Martin Fowler Testing Guide Besides all the external links, I strongly recommend the book by Kent Beck by Robert Martin. Test Driven Development: By Example and Clean Architecture Thanks a lot for reading my article. Let’s create better, more reliable and testable code together! 😊

YouTube

Follow me on GitHub

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

6 Lessons I Learned with Software Testing

Too Long; Didn't Read

People Mentioned

Company Mentioned

Igor Escodro

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

6 Lessons I Learned with Software Testing

Too Long; Didn't Read

People Mentioned

Company Mentioned

Igor Escodro

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES