At the time, I promised to write posts about my learning but ultimately I didn't. So, it is time to start now!
First of all, I wish to thanks my manager Dom Smith in Red Gate Software to offer me the opportunity to have these sessions during working hours. This really offers me the ability to have sessions regularly every week.
In this post I will condensate the learning of the last few months of mentoring with links to the various resources that I read since then.
We started discussing TDD and the approach described by Kent beck:
- Write new code only if an automated test has failed
- Remove duplications
I did the full Money example in the book TDD By Example exactly how Kent did it (with few changes as I did in C#) and deeply reflected on each step. I spent a full day to do it but it was worth the effort.
Learning well a refactoring tool like ReSharper is very important. However it is important to consider that the biggest advantages of a refactoring tool is not merely productivity:
- Avoid the human error
- Remove the context switch between using keyboard and mouse
- Shorten the feedback loop by decreasing the time needed to refactor a piece of code
- You can answer quickly questions like: Is the new design better?
Here is a collection of very useful advices:
The essence of object orientation is thinking about behaviours
TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.
Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions
I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.
- Check the error message when a test fail
- Run tests often
- After a refactoring run the tests
- Avoid copy & paste as much as possible
- When you find something to do, don't stop your current task. Add a note and do it later.
- Don't stop the flow only to rename a method or a property! Add a note and do it later.
- Primitive obsession can be often removed by introducing Value Objects
- Sometimes you can add a test and comment it out in order to do necessary refactoring
- Don't be too confident! Always use tests to validate what you are doing
- Keep tests as stupid as possible. Limit test logic as much as possible!
- In case of regression (red bar) never change test logic otherwise you won't know what was right
- If you lose control, just slow down or discard changes and restart
- Don't restrict yourself in a Top Down or Button up approach.
- The code guides you. TDD is a feedback tool.
- Consider adding code even if it is not strictly required to improve readability or simply to add symmetry
- Some tests are simply tests to support you during development. You can remove them when other tests cover the same functionalities. Don't be afraid.
- Consider the "Copy Type" ReSharper command
- The production code tests the tests!
- Extract Method is a powerful refactoring tool
- It is sometimes useful to make a private internal method public just for the sake of temporary writing unit tests but don't submit that code! Use it only to increase your knowledge about the problem.
- Learn how to do small steps when needed.
- A test is done only when duplication is eliminated!
- Consider writing a test to force the creation of an object that we expect to need late but attention of not doing upfront design
- Relying on the compiler can be a useful technique
- If it takes a lot of time to make a test green... reflect!
- Prefer static methods to factory classes when implementing the factory pattern
- Getters are smells. Pay attention to not use objects as mere data structure.
- Resist the temptation of not creating new classes... try, get feedback and see!
- Observe the frequency of change. Change should be distributed among classes.
- Use the Single Responsibility Principle to see pattern of change
- The class who own the data should do the operation: Tell, Don't Ask!
- In designing API it is best to offer a single way to do something. Make it simple!
- Use the history in SCM to get insight about your project
- Analyse temporal correlation of class changes
- If you feel that something is annoying in the code base that is a sign of poor design.
- Remain at the same level of abstraction within a test
- Write a high level test and when you see the need to cover a lot of cases go down of one level of abstraction and write more specific unit tests.
- You will often be pushing tests up and down between different levels of abstraction
- Remember to not look inside the object when you do testing even on individual classes! Test the behaviour so that you can easily change the instance of the class with a new class but keep the tests intact.
- Do not use TDD as a way to get permissions to write production code (that is cheating).
- Do not be too enthusiastic about new technologies or methodologies. Slow down and reflect. There will be always a hype and later a fall. If you are pragmatic you can fall less.
- Consider writing the assertion first
The essence of object orientation is thinking about behaviours
TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.
Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions
I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.
Quotations:
I never known exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests, Kent Beck
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order. Kent Beck
Resources:
- Book: TDD By Example
- Book: Refactoring
- Book: Implementation Patterns
- Book: Growing Object Oriented Software guided by tests
- Book: Working Effectively with Legacy Code
- Book: Holub on Patterns: Learning Design Patterns by Looking at Code
- Book: The 4 rules of simple design
- Book: ATDD By Example
- Article: Extreme Programming Values
- Article: Exagonal Architecture
- Article: The Clean Architecture
- Article: Visualizing Test Terminology
- Article: Programming like Kent Beck
- Presentation: Embrace Uncertainty, Jeff Patton
- Presentation: Theory of Constraints, J. B. Rainsberger
- Blog: Growing Object Oriented Software, Guided By Tests
- Blog: Working Effectively with Legacy Code
- Blog: Design Patterns
- Blog: The Definitive Guide to Learn JetBrains ReSharper Shortcuts in Visual Studio
)_+-+Microsoft+S.png)
)_+-+Microsoft+S.png)
)_+-+Microsoft+S.png)
