Your tests also need some architecting By Jonas Geiregat

Have you ever found yourself grappling with a hard-to-maintain or brittle test code base?
Are your tests providing you with the confidence to refactor freely and safely?
Have you encountered confusion when faced with different testing styles or approaches in a project?
Should I write an integration test, unit tests, acceptance tests or a mixture?
How do you manage test fixtures?
The world of testing can be overwhelming.
Maintaining a robust and efficient test suite is paramount for the evolution of an application.
Tests play a pivotal role in safeguarding our codebases.
Yet, all too often, test codebases become a chaotic amalgamation of ideas and approaches, jeopardizing their true purpose.
A test suite that is difficult to work with can significantly hamper the productivity and velocity of both the development team and the product
When laying down the architecture of an application, the testing aspect is often given insufficient attention.
This can lead to fragmented and poorly designed test suites that fail to fulfill their intended purpose.
It's high time that we prioritize the testing aspect and treat it as a vital component of our application's architecture.
In this talk, we will explore the reasons and motivations behind testing, allowing us to effectively address the common pitfalls encountered in test codebases.
By understanding the core purposes of testing, we can implement strategies to create maintainable and efficient test suites, ensuring the success and growth of our software projects.
JONAS GEIREGAT
Curious software engineer with a focus on all things Java.
Currently working for Cymo specializing in event driven and streaming architectures.

[@luisdanielmesa]

This is a very nice talk. I made a similar one but with fewer assumptions. He assumes there's a dichotomy between naming conventions and your code "screaming the domain" at you. That's why you have certain annotations in testing frameworks, like "DisplayName". Write a proper Java method, and annotate it with the proper DisplayName, and then you don't even have to use underscores: "Pineapple is an illegal ingredient. The cook should not be allowed to add it to the pizza". When you execute and this fails, you get a nice description of the failing test and sometimes even what is broken.
The test description (display name) should have your requirements in it. This is why certain testing frameworks try (and fail) to allow regular folk (project owners) to write tests (cucumber and gherkin syntax). The developer can spend 5 minutes writing the requirement in the display name, instead of forcing project owners to commit code: "As a cook, I want the system to prevent me from adding pineapple to the pizza because it is a forbidden ingredient". In the future the ingredient might not be forbidden, so we can modify the test to now verify it is allowed (don't ever delete a test unless it is absolutely necessary, like duplication or because it is easier to refactor it by deleting it and creating a new one instead).
Thanks for the talk.

[@SebastianPeters]

Thank you. TIL about the object mother.

[@krzysztofempicki7683]

Movie about nothing, A lot of stories about 'what I saw in previous job' , a lot of opinions and `golden` thoughts. No facts. My only expectations was that I will learn something that I can use. After 25 minutes of 'what I think' I stopped watching.