Testing is an essential part of software development, but it can also be a tedious and frustrating task. How can you design code that is easy to test, without compromising on functionality or performance? Here are some tips and best practices that can help you write testable code.
SOLID is an acronym for five principles of object-oriented design that aim to make code more readable, maintainable, and extensible. These principles are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. By following these principles, one can avoid code smells such as tight coupling, large classes, or long methods that can be difficult to test and prone to errors. Having code that is easier to read and maintain can help create a more reliable system.
Design with testing in mind (TDD). Follow the Single Responsibility Principle Write readable code. Properly comment your code. Write clear documentation.
SOLID principles keep your code small, maintainable and testable. Enforcing single responsibility is key to avoiding errors. Have your functions do one thing only. Doing that keeps the code concise and the function can be tested for its single purpose. The other principles of SOLID should be considered if desired.
SOLID principles are the result of hard work and experience. Take time to be familiar with each of the principles and revisiting them and discussing with peers is fun to do. Try to place yourself in someone that reads your code for the first time.
Design the classes in such a way that classes do not violate SOLID principle. So we can make our code modular so that its easy to maintain, refer previously available Design patterns to start your solution.
Following SOLID, DRY and TDD were the three biggest things that improved the quality of my code. TDD will naturally lead you to implement most of the SOLID principles eventually. TDD can be hard to get into, but persevere for a month and you'll soon "get" it.
Dependency injection is a technique that allows you to decouple your code from its dependencies, such as frameworks, libraries, or external services. Instead of creating or accessing these dependencies directly in your code, you pass them as parameters to the classes or methods that need them. This way, you can easily replace them with mocks or stubs when testing, and isolate the behavior of your code from the behavior of its dependencies.
Dependency injection can be implemented in different ways, such as using constructors, setters, or annotations. You can also use frameworks or libraries that support dependency injection, such as Spring, Guice, or Dagger.
Using dependency injection facilitates easier testing by decoupling components and allowing dependencies to be provided externally. By passing dependencies as parameters rather than hardcoding them within a module, you can easily substitute real dependencies with mock or stub implementations during testing.
Coding is all about making a chain of logical statements that solves a particular problem, to design a code, think of coding like building with LEGO. Break tasks into small, clear steps (like LEGO pieces), each doing one job well. Test each step separately to catch mistakes early, just like checking LEGO pieces fit. Keep pieces separate, so one problem doesn't ruin everything. Use tools to test automatically, like a LEGO machine checking pieces. Be open to change, like swapping LEGO pieces for better ones. This makes your code reliable, easy to test, and ready for anything.
Picture a car production line where diverse components must come together to assemble a car. Rather than each component having direct interactions with all the others, they are provided with the required components from external sources as necessary. Likewise, in Dependency Injection, a class does not directly instantiate another class it depends on. Instead, it obtains that external class at the time it is needed, similar to a part in a car assembly line receiving the necessary components. This approach eliminates the need to be concerned with the creation or configuration of that class; instead, it is simply utilized when required.
The inversion of control principle which is heavily related with dependency injection is something that takes time to land. But once there you wish you got that point earlier, especially when it comes to writing testable code.
Every piece of software begins with a design. A suite of self-explanatory tests is what we use to validate our design. Writing these first, and pairing each test with the minimal implementation required for the test to pass creates our first solid iteration. It also provides us with a good indication of where we need to stop.
Unit tests are tests that verify the functionality of a single unit of code, such as a class or a method. They are the foundation of testable code, as they help you ensure that your code works as expected, and that you do not introduce bugs or regressions when you make changes.
Unit tests should be written before or alongside your code, following the test-driven development (TDD) or behavior-driven development (BDD) approaches. They should also follow the AAA pattern: Arrange, Act, and Assert. This means that you should set up the initial state of your code, execute the code under test, and check the expected outcome.
Unit tests should be fast, independent, and repeatable. They should not depend on external factors, such as databases, networks, or files, that can slow down or break your tests. You should use mocking frameworks, such as Mockito, JUnit, or Jasmine, to simulate these dependencies and control their behavior.
1 test = 1 assertion. When it fails, you'll immediately get information about why without having to debug what the failure actually is. When 6 of them fail together, they tell a story themselves just by nature of their small, single responsibility. Especially if you name your tests well, which a single-assertion-only helps you achieve.
1. Make unit tests self explanatory. In the test name, include the tested method, the scenario and the expected outcome, e.g. "create_user | user without email - fails creation". 2. Make every unit test test a single scenario in order to make it easier to understand what wen wrong if it fails. 3. Test negative and error scenarios. 4. Use coverage tools to measure the percentage of code tested.
I've found it helpful to write unit tests before writing code. This gives you a validation that the test is meaning, as it should fail initially. In addition, the developed code will satisfy the requirements instead of the test parroting what the code does.
Writing unit tests is essential for ensuring code testability. By creating tests that focus on small units of code in isolation, you can easily verify the correctness of individual functions or methods. Each unit test should have clear assertions that validate the expected behavior of the unit under test. Writing unit tests helps identify bugs early in the development process and provides a safety net for refactoring and code changes.
If you only had time to practice one key skill to make your code easier to test, I would suggest applying TDD to basically everything you are writing. A lot of these tests will need to be thrown away afterwards (or heavily rewritten), but you will get testable code, because you are focusing on the behaviour of your code instead of the implementation. Write small tests with one assertion (if these assertions are complex, use a library to make it one complex assertion instead of a lot of small ones) and work your way from there. You do not have to keep doing this 100% of the time forever. Do it until it becomes natural to write testable code. You can start skipping the small tests then, but circle back to TDD regularly.
Integration tests are tests that verify the interaction between different units of code, such as classes, modules, or components. They are important to test the overall functionality and performance of your system, and to detect any errors or inconsistencies that may arise from the integration of different units.
Integration tests should be written after your unit tests, following the pyramid of testing. This means that you should have more unit tests than integration tests, and more integration tests than end-to-end tests. Integration tests should also follow the AAA pattern, but they may require more setup and teardown steps, such as creating or deleting databases, files, or network connections.
Integration tests should be run regularly, but not as frequently as unit tests, as they may take longer and consume more resources. You should use tools and frameworks that support integration testing, such as Selenium, Postman, or Cucumber.
Use TDD, write tests at first. It will help you build an app with tested business logic. Keep your test up-to-date when the business logic is changed. Use uni tests on ci, and run them ov every PR/MR.
Let the test team and product owners be involved in the beginning of the process. Definining tests at the beginning will help to clarify the specs and be prepared while development is in progress. Tools like spec flow are great to express the tests.
Writing integration tests involves verifying the interactions and compatibility between different modules or components of your system. Unlike unit tests, which focus on isolated units of code, integration tests examine how these units work together as a whole. Integration tests validate the behavior of your system end-to-end, including interactions with external dependencies such as databases, APIs, or third-party services.
I personally believe in integration and e2e tests only. Any user scenario that you want to test has to be there and work, the exact details matter less. If you have to rewrite integration and e2e tests, you know you've done a big change, or found a major gap in your implementation.
Integration tests improve code testability by : 1- validating system behavior as a whole and ensuring that it meets the desired functional and non-functional requirements. 2- Identifying cross-cutting concerns such as transaction management, security, error handling, and performance issues that span multiple components, testing real-world scenarios. 3- Validating external dependencies such as databases, message queues, web services, and cloud services. 4- detecting configuration issues such as incorrect settings, missing dependencies, or inconsistencies between development, staging, and production environments. Developers can achieve comprehensive test coverage and ensure the reliability and maintainability of their codebase.
Code reviews are the process of examining and evaluating the quality and style of your code by other developers, before merging it to the main branch. They are a valuable practice to improve your code readability, consistency, and maintainability, and to catch any bugs, errors, or vulnerabilities that may have escaped your tests.
Code reviews should be done regularly and systematically, following a checklist or a standard. They should also be constructive and respectful, focusing on the code and not on the person. You should use tools and platforms that facilitate code reviews, such as GitHub, GitLab, or Bitbucket.
Code reviews can also help you learn from your peers, and share your knowledge and feedback with them. They can also foster a culture of collaboration and accountability among your team.
It is always important to check the code, but also it is important understand why we code: First, the code shall solve a problem of a company Second, the code must be readable Third, the solution should be as simple as possible
Applying code reviews is a crucial practice for improving code quality and testability. During code reviews, team members can provide feedback on the design, implementation, and testability of the code. By having multiple sets of eyes on the code, potential issues related to testability, such as complex logic, tight coupling, or missing test coverage, can be identified and addressed early in the development process.
Using code review will help a double check of any edge case which might have been missed during the development, so getting edge cases handled at review will be better than having bug in production. It saves the developer time and give new learning to make sure that particular edge case is not missed in upcoming development
Reviewers can specifically assess the testability of the code by examining factors such as the presence of clear interfaces, appropriate use of dependency injection, and adherence to SOLID principles. They can provide feedback and suggestions for improving testability where necessary.
Only do after the fact code reviews if there is no other way. The better way to have "code reviews" is to talk about the code while it is being typed aka pair programming. In terms of "review" it is way more effective, than any sort of looking at code after it is written. If you need more than a second pair of eyes, make it a mob. In my experience nothing beats a conversation while solving the problem at hand.
Use Interfaces: Define clear interfaces for your classes or modules. This helps in creating mock implementations for testing, as well as in decoupling components.
Another aspect that I have found helpful, is by starting with testing. By employing Test Driven Devolopment it becomes easier to test your code as you implement your logic. Most Engineers will confirm that it becomes logically difficult to write tests after writing implementation logic/code.
A testable code must be understandable for everyone and achieving this goal needs to be committed to the KISS principle. Keep It Simple & Stupid.
Think about what parts of your code will be exposed to other functions, classes, modules, packages etc. What needs to be publicly accessible and what is an implementation detail, that can be hidden away and tested without setting up the complete environment and having full blown system tests.
Associate Developer at Thoughtworks ll STEM Ambassador ll British Council Scholar
Use Modularity, to break your code into smaller, reusable modules or functions. Smaller units of code are easier to understand and test. Write Clear and Expressive Naming to use descriptive names for variables, functions and classes which makes it easier to understand the purpose of each component and is easier to write tests. Other principles to apply are: Continuous integration to ensure tests are executed regularly and failures are detected early. Encapsulation to limit internal implementation details and expose necessary interfaces. This reduces the surface area for testing and prevents tests from becoming overly coupled to the implementation. By adhering to these code can be designed to be more easily tested, maintained, and extended.