I will also include some warning smells along the way. Things that will give hint your design is not testable.
1. Dependency Injection
This is one of the first things you’ll learn in doing TDD. It doesn’t matter if you’re doing London Style or Chicago Style you will eventually hit cases where you need to swap out the real item. It may be because that real object would touch the file system, a database or a network. Or it may be because it forms a convenient seam between your code and something more complex.
Smell: Singletons and classes that new their dependencies.
In a recent assessment of people applying for graduate and intern positions at my work we wanted a way to quickly assess them as a group. Ideally we wanted to see their individual skill at work, how well they worked with others and all in under an hour for groups of up to five. So I suggested we get them to do some Mob Programming on a Kata exercise. It wasn’t something we tried before but the idea wasn’t completely out of the blue.
My team has a challenge that I haven’t run into before. We all want the code to be better quality that it is now. However we don’t agree on what “better” is.
Even simple things can lead to long discussions and debates so it was a struggle to get some serious progress. Reviews could get bogged down because a refactoring someone did triggered a debate on its merit. We needed a format to allow us to work through some of the fundamentals and find where there was consensus. So I booked us in to do some mob programming together except we were not going to write new code. We were going to focus on only refactoring.