TDD and Clean Architecture - Driven by Behaviour

Speaker: Valentina Cupać
Recorded: 2022-02-01

00:00:00 Intro
00:05:20 The Talk
01:19:34 Questions & Answers

How can we accelerate the development of high-quality applications?

We will review the foundations of approaches to unit testing (Classicist TDD & Mockist TDD), specifically focusing on the structural and behavioural coupling between test code and production code, how to write more robust tests which focus on behaviour - making our tests less costly to maintain and enabling easier code refactoring without breaking tests.

We will then review how to built-in testability into architecture and how behavioural tests are the essence of use-case-driven approaches within Hexagonal Architecture & Clean Architecture.

Finally, we will conclude with insights that driving tests and architecture with behavioural modelling helps us accelerate delivery and reduce long-term maintenance costs.

Valentina Cupać is the Founder and Principal Consultant at Optivem, helping leaders of tech product companies to increase quality and accelerate delivery through technical agility. As a technical consultant and coach, she helps development teams adopt TDD & Clean Architecture in order to release new features much faster, minimize software defects, and scale teams effectively. This enables IT companies to build and scale high-performance teams, improve customer satisfaction and drive market success. Prior to 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.

Organized by: Java User Group Switzerland and Software Crafts Romandie

[alexandr]

Hi Valentina,
thanks a lot for the great talk. This one and Ian Cooper presentation on DevTernity opened my eyes: it turned out I practice almost the same approaches. But almost :)
What I realized is that integration (or component) tests are much more useful then tests on the class level and I should concentrate on them. But unfortunately still writing by inertia those class level tests with a bunch of mocks and stucking fixing them during refactoring (that I do a lot working with foreign code).
So, what my int. tests looks like: input - REST call with json, output - verify response, verify some db records, verify some external rest call (that are stubs), etc. I try to keep infrastructure for tests close to production system. Using TestContainers it is not so hard.
I practice hexagonal architecture as well. As far as I understand you consider unit-tests rather as tests on domain level. However imo it means your tests knows your code architecture i.e. implementation details. Isn't it?
What do you think if consider unit as a use case and create only integration tests on application level and do not create tests on lower levels at all? I'm talking here only about business applications without high algorithmic complexity.

[AmitLokare_]

Very well explained by Valentina.. Thank you very much

[vivekanandansakthivelu]

Excellent talk @Valentina Cupac. Thanks for the insights

[pradiptapriya]

This is interesting subjects, but I'm sorry I still can't imagine how to implemented this. From what I know until now, test driven by behavior is usually used only in instrumented test, not unit test. By testing unit test driven by behavior, won't it be covering any component used aside what users can see? For example, CMIIW, let's just say user want to login in to an application. The test should be like "When the user login with the correct credential, he can move into his account". In the implementation, the test would be testing the login usecase with a correct credential parameter and make sure that he move into his account. Is that the only test needed? Because when I think it's as structural, I would also test the whether repository or datasource classes used in that login is called and working, which covered more component that needed to make the behavior working properly, but as a user, they wouldn't know that behavior is required to use those components. So should the component like repository and datasource be not included in test at all? So what's the correct implementation test on this case?