Fitness tests, also known as architectural fitness functions, are like checkups for your software’s design. They assess how well your architecture meets specific goals with regards to architectural characteristics. Fitness tests can identify areas for improvement.
Purposes
There are many reasons why you would want to have fitness tests. These are some of the main reasons to have fitness tests for your architecture.
- Validation: Ensure your architecture aligns with the desired qualities, like performance, scalability, security, or maintainability.
- Early Feedback: Catch architectural issues early in the development process, preventing costly rework later.
- Continuous Monitoring: Integrate fitness tests into your build pipeline for ongoing feedback on architectural health.
- Communication: Provide objective measures to communicate architectural decisions and trade-offs to stakeholders.
Platform Agnosticism
The core concept of fitness tests is platform-agnostic. They focus on architectural qualities, not specific implementation details. You can apply them to various platforms (web, mobile, embedded systems) as long as you can measure the desired characteristics.
Platform-Specific Tools
While the core concept is agnostic, specific tools and metrics used in fitness tests might vary depending on the platform. For example, a fitness test for performance on a web application might involve measuring response times under load, while a mobile app might focus on battery consumption.
Some ideas of tools that are used for various platforms include:
- C#: SonarQube (code analysis), BenchmarkDotNet (performance), Chaos Monkey (resilience), ArchUnitNet (rules), Grafana k6 (load testing)
- Java: SonarQube (code analysis), ArchUnit (rules), jMeter/Gatling (performance)
- Python: Pylint/Flake8 (code analysis), pca-archunit (rules), Locust (performance)
- Go: Staticcheck /Go-Critic (code analysis), GoConvey (test qualities), Hey (performance)
Examples of Specific Tests
Suppose we have a pizza system called NimblePizza. (We mention this name in our webinar on Design Patterns for Testing!) These are some fitness tests that we could have in our system.
Scalability
For scalability testing, we could use load testing tools to simulate a high volume of orders. For example, suppose we get big enough that we’re the official pizza of a future SuperBowl. We want to make sure we can scale our services under certain loads. Use these tests to ensure that your system can scale and perform well.
Security
For security testing, we could have fitness tests in place to ensure the data is getting stored properly and is locked down properly.
Maintainability
For maintainability, we can have fitness tests to ensure that code metrics such as degree of coupling are set within certain tolerance levels. This can be done with something like ArchUnitNet.
Availability
For availability, we would want to analyze our system to ensure there isn’t a single point of failure that could bring down the entire syste,
Other Tests
Other tests we could do include:
- Order Cancellation Test: Simulate order cancellations at different stages of the process (before payment, after payment) and verify the system handles them correctly, including updates to inventory and customer notifications.
- Email Delivery Test: Set up automated tests to ensure emails (order confirmations, invoices) are delivered successfully and contain the correct information.
Conclusion
By combining these tools with well-defined architectural goals, you can create a comprehensive set of fitness tests for your systems. With some of these tools, you can create automated tests to ensure that your architectural goals are being met and audited regularly. When it comes to making architectural decisions, also consider how you can ensure that your architectural goals are considered and met.