Architecture
Improving your Test Driven Development in 45 minutes.
I’ve been using TDD/BDD at work for the last 12 years, I also teach and mentor teams on this subject. I’ve found that misconceptions and errors in this field are shared, and that most of us make the same mistakes. Give me 45 minutes of your time, and I’ll try to address the most common problems, hoping to improve your TDD/BDD situation as much as possible.
I’ll try to solve:
Long running tests problem, by bringing back the correct shape of test-pyramid with power of Hexagonal Architecture (Ports & Adapters) with practical examples in Spring.
Miscommunication and lost art of requirement gathering, by focusing on readability, introducing just enough of Domain Specific Language, and sorting out what is important with the power of Spock.
Difficult test setup and environment requirements, by using command and conquer, modularity, monitoring.
Mock abuse, by showing what are the benefits of in-memory implementations.
And hopefully more.
Most teams that do not write tests first do it, because it’s hard for them. I’ll try to show you, how to make it easy. Real life examples included.
If you are not using TDD/BDD, this might also interest you - you’ll know how to start the right way.
Methodology & Culture
User Stories considered harmful: why Product Owners and developers failed at gathering requirements and communication
Long time ago there was a role of a business analyst, who would discover and gather client requirements, then together with a system analysts, write them down. Next, they would meet an architect, where they would analyse the impact of those requirements on the architecture, and impact of architecture on business opportunities. This collaboration would provide new ideas for the business, but most of all, would create the analysis that went to developers.
Then there was the famous C3 project with Kent Beck as the leader. There was no time for formalities, so a new method was born, called eXtreme Programming (XP).
Then came Scrum and Kanban with Scrum Masters and Product Owners. Neither of them had any experience with XP, but since they loathed the old world, they have fired all the system and business analysts.
And so, two working methods of requirement analysis were replaced by a single ineffective meeting called "grooming", where a seven plus/minus three people, without any preparation, try to estimate something that nobody took time to understand.
I'd like to show you how we came to this point, why the current situation puts developers in jail, and how to solve this madness.