Clean architecture under test
Enterprise products, instead of being large monoliths, became rather a set of small, well integrated yet independent applications. Designing test automation in a distributed environment has always been a challenge.
During this workshop I’d like to focus on:
- inter-application testing – what types of tests should be used in which parts of our system?
- cross-application testing – how clean architecture helps us while introducing consumer driven contracts?
I will shed some light on the everlasting discussion about using mocks in tests, when it makes sense and when we should rather avoid them. I will show how domain driven design concepts fit nicely into clean architecture and how it all together helps us to design our test framework, and test suite efficiently. We’ll give an answer to a question “what is a unit?”, and last but not least, cross-application integration tests, the most expensive ones… Clean architecture if implemented with discipline combined with consumer driven contracts allows us to perform such tests with a speed of a unit tests (each test lasting few milliseconds).Static code analysis is a must-have hence I will cover this part as well. Nevertheless we’ll go one step further, instead of testing the code itself we will focus on testing if changes conform to architecture of the application. I think that in an agile world where the difference between a tester and programmer gradually vanishes, testing cleanliness of a software architecture will soon become similarly common as boundary values analysis.
During the workshop we will focus on writing a spring boot rest service in BDD/TDD style. Following aspects will be covered:
- Consumer driven contracts (e.g. service-service integration)
- Automated system tests (e.g. end-2-end service tests)
- Automated integration tests (e.g. service-db integration)
- Sociable unit tests
- Solitary unit tests
- Static code analysis
Maximum number of participants: 10
Preliminary requirements for participants: Workshop aimed for experts in test automation. The level of advancement of the candidates will be verified by a task before the workshop. Admission to the workshop will depend on it.
Agile testing trainer and a member of a mature Agile team, for years working on assuring quality not only of a software but also quality of a software development process.
Together with his team, he’s made a journey from SCRUM to Kanban. This experience taught him that every stiff rule has its price and needs to be not only thoroughly understood by those upon whom it is imposed, but also should be constantly revisited by those who impose it.