🗞 Stream Recap: Test-driven Development with Jonathan Hall
Our Tech Journey #4—Here's what you missed
Thank you to the 24 live attendees. Over 230 people have now watched our conversation a week later.
Talking Points
“TDD is a hot-button issue. […] People have different perceptions on what it is.”
“Where are the problems/risks of TDD on the business view?”
“TDD is not magic. It’s a discipline. Just like brushing your teeth or doing a pushup. It doesn’t make you go to the gym and lose weight magically.“
“Tests need to be simple, expressive and they must run fast.“
“End-to-end tests are not unreliable because they are “evil”, the issue is that they have the most implementation-coupling compared with any other form of test.“
“What do you think about monitoring in combination with TDD? Is monitoring more valuable than TDD or is it a good combination? Or leave TDD and only do monitoring?”
“End-to-end tests used as high-level API tests help as a temporary solution to deal with an untested legacy refactoring effort.”
“Is TDD JAF (Just Another Fad) in technology? Does TDD result in more
stable, tighter, safer (more secure) code? How do you know?”“Focus on increasing your capital efficiency of your tests. You want to minimise the coverage each test gives you. This is unintuitive. You don’t want a very large test—measured in LOC—giving you too much coverage. That’s E2E testing. You want a minimal, small unit appropriately testing and covering a slightly larger piece of behavior.“
“[…] Does TDD bring you more time to bring the product to the market? What do you think?“
“It may take longer to write or think about a task, depending on the problem. But as soon as they make changes to it they’ll be grateful they wrote it using TDD.“
“Should we write test's for the null or undefined arguments?”
“The most important aspect of code: can it be modified easily and safely? As you become proficient in TDD and design—[…] that can take a while— I believe it will always make you faster.“
“Do you spend half your time debugging problems, and end up with many errors in production? Or do you spend the same amount of time testing as you go, so you always have something rock-solid-reliable to release?”
Recordings
Highlights (AI generated)
Test-driven development is a welcome addition to any engineer’s toolkit given the right circumstances. However, not all organizations are set up in a way to benefit from it well.
00:00 Test-driven development encourages thinking about the business problem and feature expression, providing a methodology for evaluating work equally and emphasizing the customer-facing side of development.
TDD’s impact on engineering culture, and the emotional and psychological state of the team, with a focus on adoption and nuance in different project contexts.
Misconceptions and controversies surrounding test-driven development, emphasizing the importance of a test list in project management and sharing their personal approach to TDD.
Benefits of test-driven development and the need for writing a list of tests based on the complexity of the algorithm or user interaction levels.
TDD is a discipline that encourages thinking about the business problem and feature expression, rather than just implementing algorithms, and it is not a magical solution but a framework to help keep developers on track.
Test-driven development is about thinking about where tests belong in order to prove correct behavior, and it provides a methodology for evaluating work equally.
Upgrading modules or dependencies can cause issues when deploying on different servers or in different availability zones.
22:14 Test-driven development ensures stable, secure code by providing immediate feedback, forcing teams to think about security, and focusing on integration and unit testing over end-to-end testing.
Test-driven development ensures that code is stable, safe, and secure by providing immediate feedback to developers and requiring all tests to be green before pushing changes.
Test-driven development is not a fad, it forces you to think about security and enables a team to create more secure code.
TDD helps expose security vulnerabilities and can be used to test security requirements, but it is not the main purpose of TDD.
End-to-end testing can cause bottlenecks in time to market, and it is better to focus on integration and unit testing as end-to-end testing should be a minority.
End-to-end tests are expensive and unreliable because they are the most extreme coupled version of a test, testing implementation details rather than the logical design of functionality, but they may be necessary for new projects with poor test coverage.
Start by writing end-to-end tests to gain confidence for refactoring, but aim to eventually remove them as a temporary step towards the ideal.
39:29 Test-driven development focuses on minimal test coverage, leading to more modular and easily modifiable code, ultimately saving time and ensuring the product works as intended.
Focus on minimizing the amount of coverage obtained from each test in order to effectively implement test-driven development, especially in Brownfield projects without existing tests.
The goal of test-driven development is to write minimal lines of code in tests to achieve an appropriate level of coverage, and to agree upon a minimal setup for different types and sizes of tests.
Test-driven development may take longer initially, but it leads to more modularized and easily modifiable code, ultimately saving time in the long run.
Testing code with Test-driven development (TDD) saves time and ensures that the code is ready and accepted by the market, avoiding manual and slower testing methods.
Some people may believe that writing tests is harmful, but for products with a large user base like Facebook and WordPress, testing in production can provide faster and more valuable feedback.
Testing is important despite arguments against it, as it helps manage anxiety and ensures that the product works as intended.
51:54 Test-driven development encourages isolating new functionality for easier testing, reduces speculation, and can be used as a KPI to identify pipeline issues, while also being important to motivate people to learn.
Inexperienced developers may experience more burnout with trunk-based development, while more experienced developers benefit from it, and the transition from git flow to CI/CD can be stressful for some.
Test-driven development allows for code to be easily handed off, reduces speculation and last-minute testing, and encourages isolating new functionality for easier testing and improved design.
Use TDD as a KPI to identify pipeline issues, and consider pairing as a practical way to teach TDD, as it can take a long time to appreciate through trial and error.
Focus on motivating people to learn test-driven development, as it is more important than the technical how-to.
TDD can be applied to programming with inconsistent outputs by creating a testing plan based on expectations and understanding statistics, and by capturing the human element of determining success in code.
01:08:27 Good monitoring practices and TDD are valuable, but should not be mandated and developers should be responsible for the quality of their code.
Good monitoring practices and TDD are both valuable and should be taught to engineers, allowing them to decide the extent to which they want to implement each, even if they have reasons not to do so.
Check for any negative attitudes or competition around test writing, disincentivize harmful behavior, and adapt to changes in context to encourage test-driven development.
TDD can improve wellbeing and productivity on most projects, but it may not work for certain legacy projects and there is toxicity around it that can be harmful.
Mandating TDD practices can be compared to mandating physical activity at work, with some people feeling it breaches boundaries and should only be mandated in a training environment.
Mandating test-driven development may be considered rational, but it should be approached on an outcome basis rather than forcing it upon individuals.
Developers should be responsible for the quality of their code and should be held accountable for fixing their own bugs, whether achieved through TDD or not, in order to instill a sense of responsibility and improve code quality.
01:22:04 Testing is crucial for high-quality software development, and engineers need to prioritize it as part of their business responsibilities to fulfill contracts and create usable output.
Demonstrating relevance in testing and the analogy of maintaining cleanliness in a bed and breakfast.
Teams often take the stance of blaming requirements instead of collaborating with the customer, which goes against the principles of agile software development.
Quality and discipline in software development are important, and assuming that the customer doesn't care if the code is tested is a logical fallacy.
Customers expect high-quality software and do not explicitly care about testing, they just want the product to work properly.
Tests are necessary for developers to ensure that expectations are met, and engineers should understand that they are part of a business fulfilling contracts and creating usable output, while also being mindful of incentives that may influence their decisions.
Engineers need to prioritize the capital efficiency of their work and testing regimen, as it cannot be delegated and will constantly frustrate them if not addressed regularly.
01:34:55 Developers should seek customer feedback, prioritize valuable work, and avoid relying solely on QA for verification in software development.
Shift left behavior is important in software development, with QA serving as consultants for developers to ensure that requirements are understood and quality is maintained before code is pushed.
Developers should understand customer requirements and seek feedback from them, rather than relying on QA teams, and should work in smaller iterations to get feedback faster.
Customer feedback can either concentrate decision-making power for a product team or dilute it for a cost center, and the core problem lies in the unverified opinions of the developer and QA about what the customer wants.
Using QA for independent verification does not improve quality, instead, have QA do exploratory testing to find new ways to optimize user flows and improve the system.
Capture the business outcomes in the requirements to enable the team to own the problem and prioritize valuable work based on customer feedback.
Respond to customer needs without relying on a backlog, as customer feedback can get lost in a backlog-driven culture.
01:47:23 Test-driven development is essential for identifying business problems, preventing backlog issues, and improving communication with clients, while also emphasizing the importance of learning and understanding the concept and problem-solving aspect of TDD.
There is no one-size-fits-all answer for test-driven development, as it depends on individual approaches and opinions.
The backlog problem in development is often caused by a disconnect between the development cycle and the requirement and design cycle, leading to a communication issue with clients and a stagnating backlog, which can be reduced by implementing continuous delivery and involving product owners and designers in the development cycle.
TDD is essential for identifying business problems and ensuring a clear understanding of the problem before writing code, and it also helps in the exploratory phase of coding.
Testing code should focus on the order and decisions of what to test, avoiding building up a system where each test is essentially a line of code, and being intentional and learning how to write good tests.
Results of an informal poll on TDD usage and the importance of focusing on those who are challenged by TDD, while also highlighting the benefits of learning about prevention through TDD.
Jonathan Hall discusses his experience with test-driven development, recommends books and resources for learning TDD, and emphasizes the importance of understanding the concept and problem-solving aspect of TDD.
Archive
You can always find the archive of the Thursday shows on the Stream Recap section and the Wednesday episode on the SnackableCTO. We’re still figuring this out.
The Test Desiderata offers precise vocabulary to discuss some of the properties of tests you covered.