Рет қаралды 8,563
How do we approach system design? Do we design systems top-down or bottom-up or both? Do we design systems by starting from the system periphery and moving inside, or do we start from the system internals and then move outwards to the periphery?
With Use Case Driven Design (UCDD), we start design from the outside, we start from the system boundary, the user-side API and the server-side API, and then we move inside, into the domain. In this approach, our unit tests are targeting use cases (thus treating the system as a blackbox), as we are interested in observable behavior only at the architectural boundary. The system domain is just an implementation detail.
With Domain Driven Design (DDD), the domain model itself is the essence. In this case, our unit tests are targeting domain elements, for example targeting aggregates to testing aggregate-level behavior, also targeting domain services to test behavior which doesn’t belong to a single aggregate. The application services are merely thin wrappers to expose the behavior to the external world.
The question is, should our tests target use cases, the domain model, or both?
In this presentation we will presenting the following approach to TDD, UCDD, DDD:
1. Adopting Use Case Driven Design for modeling the system behavior, writing unit tests coupled to use cases in order to express executable requirements of system behavior
2. Adopting Domain Driven Design for modeling the system structure, enabling behavior to emerge within the domain through refactoring the use cases (we can safely shift between anemic and rich domains, or even shift between programming paradigms without breaking our use case tests)
3. Understanding how use case unit tests are more robust to refactoring as opposed to domain tests, but also recognizing the situation when we need to "shift gears" to write domain-level tests
We will illustrate the above approach with the Banking Kata (Java) and Banking Kata (.NET) - including Unit Testing, Integration Testing and System Testing within Clean Architecture. Additionally, we will also evaluate the quality of our Test Suite with Mutation Testing.
Java: github.com/val...
.NET: github.com/val...
Valentina Cupać is the Technical Coach & Founder at Optivem, helping software product companies to deliver better software faster with TDD and Clean Architecture. She helps development teams release new features much faster, minimize software defects, and scale teams effectively. Before coaching, Valentina had extensive hands-on experience in software development - as a Senior Software Developer, Tech Lead, Software Architect, and Solutions Architect. She has graduated with a dual degree from the University of Sydney, majoring in Computer Science, Advanced Mathematics, and Finance.