Class#8 - TDD and BDD Presentation PDF

CLASS#8 – TDD AND BDD BDD & TDD Acceptan ce Testing Behavior Driven Development System Doing right thing? Testing Integration Testing Test Driven Development...

CLASS#8 – TDD AND BDD BDD & TDD Acceptan ce Testing Behavior Driven Development System Doing right thing? Testing Integration Testing Test Driven Development Doing things right? Unit Testing WHY DEVELOPERS FEAR CODE MODIFICATIONS? 1. They fear introducing bugs 2. They don’t know how to keep it clean 3. They don’t want to spend the effort of clean up 4. They know their code is already working – they tested it manually. “ "if you fear it you cannot clean it; if you cannot clean it, the only thing that can happen to it is that it must rot“” HOW TO HANDLE THAT FEAR? 1.Embrace Fearless Competence: One common issue is the hesitation to touch code due to the fear of breaking it. Developers often think, "Oh, it's a little ugly; I should clean it," but then refrain from acting because they worry about the consequences of changes. Acknowledging this fear and understanding that it's a normal part of the coding process can help developers approach modifications with a more positive mindset. 2.Implement a "Clean Code" Button: Imagine having a metaphorical button that allows you to clean and improve the code effortlessly. If developers could easily clean the code, it would encourage them to make changes without fear. This concept emphasizes that if code is consistently improved, it becomes easier to modify, leading to faster development cycles. 3.Practice Incremental Changes: Instead of making large, sweeping changes, developers can start with small, incremental modifications. This approach reduces the perceived risk and allows for easier troubleshooting if HOW TO HANDLE THAT FEAR? 4.Create a Testing Environment: Setting up a safe testing environment where developers can experiment with code changes without affecting the main codebase can significantly reduce fear. This allows for trial and error without the pressure of breaking anything critical. 5.Peer Reviews and Pair Programming: Collaborating with peers can provide support and reassurance. Pair programming or code reviews can help developers feel more confident about making changes, as they have someone to discuss potential impacts with. TDD Test Driven Development steps: 1. Write a failing test (Red). 2. Write just enough code to pass the test (Green). 3. Refactor the code for optimization without changing functionality. ADVANCED TDD TECHNIQUES 1. Factories: Used to create objects with specific states or configurations, simplifying object creation. 2. Fakes: Simple implementations of interfaces or classes used to mimic the behavior of real components. 3. Mocks: Objects that record interactions, verifying that methods are called with expected arguments. 4. Stubs: Simplified objects with predefined responses to simulate real components. 5. Spies: Record method usage to verify interactions, such as the number of times a method was called. 6. Dependency Injection: A design pattern where dependencies are injected into a class, promoting flexibility and testability. 7. Behavior Verification: Ensuring that the system behaves as expected, verifying FACTORY Purpose: Factories are used to create objects in a controlled manner, often used in tests to generate instances with specific states or configurations. Usage: They simplify object creation, especially when objects have complex initialization. Helps in setting up test environments quickly by reusing factory methods to create needed objects. FAKES Purpose: Fakes are simpler implementations of interfaces or classes used in place of real implementations for testing purposes. They mimic the behavior of real components with minimal functionality. Usage: Useful for testing in isolation without relying on external systems like databases or APIs. MOCK Purpose: Mocks are objects that record how they were used (methods called, parameters passed, etc.) and can verify that certain interactions occurred during the test. Usage: They allow you to simulate and verify interactions with dependencies. Ensures that expected methods are called with the correct arguments. STUBS Purpose: Stubs are simplified objects with predefined responses, used to simulate the behavior of real components. Usage: Unlike mocks, stubs do not track or verify interactions. They are used to provide fixed responses to method calls during tests. 100% test coverage = 100% bug free? 100% TEST COVERAGE = 100% BUG FREE? The goal is to achieve 100% test coverage, which represents that every line of code is executed during testing. However, it's important to note that while 100% coverage is an ideal target, it's often unattainable in practice. High code coverage boosts confidence in software reliability, but it doesn't ensure quality if tests are insufficient. A passing test suite with gaps can mislead about the code's robustness, creating a false sense of security. BENEFITS OF TDD Improved Code Quality: Writing tests first ensures that the code meets the requirements and behaves as expected. This leads to fewer bugs and higher quality code. Reduced Debugging Time: Since tests are written before the code, many bugs are caught early, reducing the time spent on debugging later. Enhanced Design: TDD encourages developers to write simpler, more modular, and maintainable code. The need to pass tests drives better software design. BENEFITS OF TDD Faster Feedback: Immediate feedback from automated tests helps developers catch issues quickly, leading to faster iterations and more agile development. Encourages Continuous Improvement: The iterative nature of TDD fosters a mindset of continuous improvement, where code quality and design are constantly enhanced. TDD LIMITATIONS 1.Initial Learning Curve: 1. For developers new to TDD, there's a learning curve to writing good tests before the actual code. 2. It may take time to get used to the discipline required for TDD. 2.Time-Consuming: 1. Writing tests before coding can slow down initial development. 2. Creating and maintaining a comprehensive test suite requires ongoing effort. 3.Complexity in Testing: 1. Writing tests for complex scenarios, such as user interfaces or multi-threaded code, can be challenging. 2. Tests may need to be updated frequently if the system architecture changes. TDD LIMITATIONS 4. Overhead in Small Projects: For smaller or simpler projects, the overhead of TDD might not be justified. 1. The cost-benefit ratio may not be favorable for very small codebases. 5. False Sense of Security: 2. A complete test suite can give a false sense of security. Not all bugs can be caught by automated tests. 3. Tests need to be well-designed and cover edge cases to be truly effective. 6. Resistance to Change: 4. Some developers or teams may resist adopting TDD due to comfort with existing practices. 5. There may be organizational barriers or lack of management support for implementing TDD. BDD & TDD Acceptan ce Testing Behavior Driven Development System Doing right thing? Testing Integration Testing Test Driven Development Doing things right? Unit Testing BDD What is BDD? A collaborative approach to software development that encourages communication between developers, QA, and non-technical stakeholders. Focuses on defining behavior of software through examples in plain language. Why BDD? Improves understanding and communication among team members. Ensures that software meets business requirements. Reduces misunderstandings and rework. BDD Tests written in plain language using "Given-When-Then" structure: Given: Initial context. When: Action or event. Then: Expected outcome. Some tools that support BDD: Cucumber, SpecFlow, Behave.  HOW TO GET STARTED? 3 Amigo’s meeting: - Request - Suggest - Protest 3 AMIGOS MEETING Is the What initial happens request if …? correct? (Protest) Doable? (Request) How we will build this..? (Suggest) BDD GHERKIN EXAMPLE EXAMPLE CUCUMBER EXAMPLE HTML REPORT Clean Code and bad code - https://www.youtube.com/watch? v=vsQya8Ai1jw