I have been using TDD/BDD at work for 12 years, teaching and mentoring teams in this field. I have found that misconceptions and mistakes are common in this field and that most of us make the same mistakes. Give me 45 minutes of your time and I will try to address the most common problems in the hope of improving your TDD/BDD situation as much as possible.

I will try to solve the problem:

Long-running test problem by restoring the correct shape of the test pyramid with the power of hexagonal architecture (ports and adapters) and practical examples in Spring.

Misunderstandings and lost art of requirements gathering by focusing on readability, introducing just enough domain-specific language and filtering out what's important with the power of Spock.

Difficult test setup and environment requirements due to use of Command and Conquer, modularity, monitoring.

Mimic abuse by demonstrating the benefits of in-memory implementations.

And hopefully more.

Most teams that don't write tests do so because they find it difficult. I'll try to show you how to make it easy, including real-life examples.

If you are not using TDD/BDD, you might also be interested in this – here’s how to get started right.

Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.