Rewiring your brain with test driven thinking in C++ - Phil Nash - Meeting C++ 2023

[@not_ever]

This is a really great talk but I have one personal rant to go on. Test as documentation only works if people write good tests. No one should be expected to wade throught your unit tests all named test_1 test_2, etc. in files named, test_1.cpp test_2.cpp etc. to find out how your shitting code works and yet that is what people are expecting commonly others to do. I've seen issues where the developer has said to someone, just look in the unit tests, has no context as to where that unit test is and assumed that they will never in the future change/delete/move the test and the tests are named exactly as I have described. Tests as documentation is a whole talk by itself. Maybe if Phil Nash ever reads this comment he might like to give it. I very much enjoy his talks.

[@wolpumba4099]

*Summary* *Introduction and Background* - 0:01 - Debunking the myth that we only use 10% of our brains. - 0:29 - Exploring ways to use our brains more effectively for specific tasks. - 0:47 - Speaker's first conference talk nearly 20 years ago on "organic programming" and productivity hacks. - 1:11 - Shift from niche to mainstream ideas in productivity and psychology. - 1:23 - Interest in Test-Driven Development (TDD) and creating the test framework Catch. - 1:45 - Combining productivity techniques and TDD for enhanced results. - 2:04 - Presenting a talk on the psychological underpinnings of TDD. - 2:29 - Introduction of the speaker, Phil Nash, developer advocate at Sonar. - 2:35 - Sonar's focus on static analysis tools for code quality. - 3:06 - Contact information for Phil Nash and reference materials for the talk. *The Fundamentals of Testing* - 3:39 - Discussing the fundamentals of testing and why tests are written. - 3:58 - Audience engagement on their testing practices. - 4:27 - Questioning why developers don't write enough tests. - 4:50 - Exploring common reasons for not writing tests, such as extra work, slowing down, distraction, and boredom. - 6:41 - Why tests are written: catching bugs, encoding expectations, catching regressions, documentation. - 7:46 - Listing additional benefits of testing, particularly in TDD. - 9:18 - Comparing benefits of general testing versus TDD-specific benefits. - 10:13 - Claims that tests can reduce rework, speed up development, keep focus, and be enjoyable. *Psychological Aspects of TDD* - 11:13 - How to achieve these claims through the psychology of TDD. - 11:37 - Emphasizing the brain as an association machine, linking neurons to behaviors, emotions, and mental resources. - 12:23 - Importance of understanding our brain as an association machine for context. - 12:37 - Discussion of three areas: habit forming, dopamine triggers, and externalizing the brain. - 12:47 - Emphasizing habit forming as crucial for TDD practice. - 13:05 - Exploring dopamine triggers in relation to TDD. - 13:18 - Concept of externalizing the brain for maintaining focus without losing the big picture. *TDD in Practice* - 13:32 - Introduction of "a tale of two cycles" with a personal photo. - 13:50 - Explanation of the TDD cycle: Red Green refactor cycle. - 14:33 - Adding an "Are we done?" step to the TDD cycle. - 14:45 - Detailed walkthrough of the TDD cycle starting with writing a failing test. - 15:12 - Importance of intentional failing tests in TDD. - 15:29 - Different forms of failing tests, including compiler errors. - 15:50 - Writing code to pass the test, focusing on simplicity. - 16:39 - Separating clean code concerns into the refactoring phase. - 17:04 - Benefits of isolating changes during the green phase to avoid breaking other code. - 17:41 - Deciding when we are done with a cycle and if more tests are needed. - 18:01 - Demonstrating TDD with a reconstructed demo in slides. - 18:13 - "Leftpad" programming exercise in C++ using Catch. - 19:07 - Setting up a test environment and understanding the starting point. - 19:27 - Writing an empty test case to understand different feedback from the test framework. - 20:10 - Demonstrating the TDD cycle with simple assertions. - 20:41 - Incremental development using Leftpad function as an example. - 21:03 - Starting with the simplest possible values in both tests and implementation. - 22:04 - Ensuring a failing test is seen before making it pass. - 22:17 - Creative approaches to generating a failing test when necessary. - 23:25 - Gradually increasing complexity in tests while maintaining simplicity. - 24:01 - Progressing from hardcoded constants to conditional logic in implementation. - 24:44 - Using simple changes to pass tests, then increasing complexity as needed. - 25:21 - Fixing an issue in the Leftpad function by correcting the order of arguments. - 25:45 - Combining non-empty strings and non-zero pad lengths in the next test. - 26:09 - Adjusting the Leftpad function to correctly handle string concatenation and padding. - 26:36 - Addressing the need for a refactoring step in TDD. - 27:00 - Discussing the single assert rule in test cases. - 27:36 - Beginning refactoring of the Leftpad function, starting with clarifying variable names. - 28:24 - Attempting to simplify the implementation by combining string conversions. - 29:01 - Encountering and debugging an exception caused by unsigned integer subtraction. - 29:49 - Fixing the issue with correct integer types and reducing implementation to two lines. - 30:19 - Discussing potential performance improvements and different implementation styles. - 31:04 - Demonstrating how TDD works in practice, with a focus on the Red Green refactor cycle. - 31:29 - Discussing when TDD testing is considered complete and exploring additional testing methods like property-based testing. *Concluding Insights and Q&A* - 32:49 - Introducing the concept of the habit forming cycle in the context of psychology. - 33:16 - Emphasizing the difficulty in breaking habits and the importance of replacing them with stronger ones. - 33:50 - Describing the components of a habit: cue, behavior, and reward. - 35:31 - Identifying the reward in habit loops and the challenge of finding equivalent or bigger rewards for habit replacement. - 36:03 - Highlighting the ineffectiveness of long-term goals in motivating habit change. - 36:35 - Proposing a TDD habit loop: writing code with tests first for immediate positive feedback. - 37:17 - Explaining the repetitive nature of TDD cycles and their potential for forming habits. - 37:48 - Discussing the difficulty of not following established habits, leading to writing code primarily with TDD. - 38:15 - Exploring the concept of dopamine triggers in relation to pleasure and motivation. - 38:45 - Exploring the nuanced understanding of dopamine as a motivator, not just a pleasure chemical. - 39:03 - Dopamine confers motivational salience, focusing attention on establishing important facts or patterns. - 40:04 - Example of monkeys pulling a lever for treats illustrates dopamine's role in pattern recognition. - 41:12 - Identifying dopamine triggers in TDD, such as seeing tests pass and the liberating nature of coding in the green phase. - 41:53 - Dopamine helps in staying motivated, learning from mistakes, and enjoying coding. - 42:51 - Discussing the concept of externalizing the brain to better focus on specific tasks. - 43:05 - Brains operate best not in isolation but in conjunction with others or external tools. - 43:54 - Utilizing tools like mind maps and computers to free up mental capacity. - 44:38 - Different roles and mindsets in each stage of TDD: Red (user experience), Green (implementation), and Refactor (low-level design). - 47:43 - Encoding a test as a "mental save point" allows focusing on the next task. - 48:03 - Overview of the three areas covered: habit forming, dopamine triggers, and externalizing the brain in TDD. - 48:31 - Arguing that TDD makes coding fun and keeps focus on what matters by embedding requirements in tests. - 49:35 - Addressing concerns about TDD being more work and potentially slowing down the process. - 49:53 - Introducing the concept of 'shift left testing' to fix defects earlier in the development cycle. - 51:05 - The earlier a defect is fixed, the less costly it is in terms of time and resources. - 51:27 - TDD moves defect fixing to before coding, saving more time and resources. - 51:40 - TDD also aids in the design and analysis stages, encouraging questioning of requirements. - 52:05 - Behavior-Driven Development (BDD) involves conversations with domain experts to establish requirements before coding. - 52:24 - BDD is similar to TDD but occurs earlier in the development cycle. - 52:36 - TDD saves time by avoiding rework. - 52:41 - Analogy: Cars have brakes so they can go faster, just like tests in TDD provide confidence to code faster. - 53:05 - Tests in TDD act like brakes, giving confidence to take risks and make big changes. - 54:01 - TDD helps in focusing and making coding fun. - 54:12 - Link provided for further reading: levelofindirection.com/refs/rewire.html - 54:47 - Question about the 'require' macro in Catch tests and whether 'check' is better. - 55:01 - Explanation of 'require' aborting immediately if it fails, while 'check' continues running subsequent assertions. - 56:03 - Discussion on challenges in getting team and business buy-in for TDD and BDD. - 56:23 - Suggestion to demonstrate TDD and BDD as fun and productive in a non-project setting. - 57:04 - Challenge of adding tests to existing code without clear requirements. - 57:38 - Mention of approval tests as a way to lock in current behavior when adding tests to legacy code. - 58:23 - TDD strategy: write one test, then implement, then write the next test, to adapt to design shifts. - 59:10 - Writing multiple tests ahead may lead to rework if the design changes. - 1:00:27 - Question about the risk of breaking tests themselves during refactoring or design changes. - 1:01:26 - Two reasons for breaking tests: changed requirements or testing implementation details instead of public interfaces. - 1:02:41 - Potential challenges of having separate teams for testing and implementation in the context of TDD.

[@sajjadkarbasi281]

very nice talk i realy liked it and gonna use more TDD in my code

[@briansalehi]

Great impression on Test Driven Development. Not an introduction though. I suggest reading Test Driven Development book by Kent Beck for ones not familiar with the concept. This talk moves the discussion on TDD further by providing a way you can psychologically convince yourself you need to take TDD into account. My point of view is that I can't imagine writing good code without test anymore.

[@chillosophification]

Thank you for describing the video, now i will watch it entirely.

[@victotronics]

Why do you write tests? Do get confidence that your code computes the right thing. In scientific computing, code computes something you don't know yet; it's like running an experiment. So you the only way you can check whether your result is right, is extensive testing of all the code bits.

[@perghosh8135]

If developers code like this they will never be ready or if they are ready no one will have the time to refactor code to make it better. Coding like this is insane