Overview<br />Introduction<br />Extreme Programming (XP)<br />Tests<br />Stress and Tests<br />What is Test-Driven Development?<br />Misconceptions About TDD<br />Motivation<br />The TDD Methodology<br />Benefits<br />How?<br />Patterns For TDD<br />Vulnerabilities<br />Questions<br />
Introduction<br />Agile methods – Group of S/W development techniques based on iterative development<br />Breaking tasks into small increments with minimal planning<br />Techniques such as continuous integration, automated test, pair programming, test driven development, design patterns, code refactoring and other techniques are often used to improve quality and enhance project agility<br />
Extreme Programming (XP)<br /><ul><li> XP - Software development discipline
responsiveness to changing customer requirements.
Type of Agile Development advocating frequent releases
Using extreme techniques like Pair Programming, TDD, avoiding programming features until needed.</li></li></ul><li>Tests<br />We need to answer some basic strategic questions before we can talk about the details of TDD:<br />What do we mean by testing?<br />When do we test?<br />How do we choose what logic to test?<br />How do we choose what data to test?<br />How do you test your software? <br />
Stress and Tests<br />What happens when the stress level rises?<br />How do you get out of such a loop?<br />
What is Test-Driven Development?<br />In principle, it is just about writing the test before the program.<br />But in consequence, it leads the developer to<br /><ul><li>first think about “how to use” the component (why do we need the component, what’s it for?)
and only then about “how to implement”.</li></ul>So, it’s a testing technique as well as a design technique<br /><ul><li>It results into components that are easy to test.
It results into components that are easy to enhance and adapt.</li></ul>In the end, there is no code without a test.<br />The developer can tell at any time<br /><ul><li>whether everything still works as it should, or
what exactly does no longer work as it once did.</li></li></ul><li>Misconceptions About TDD<br />Creating unit tests may add time to the overall development cycle<br />Time spent in UT should produce higher quality, better designed software with fewer bugs<br />Implies software can be delivered faster.<br />TDD makes the developer's focus too narrow and prevents the developer from seeing the big picture<br />Allows constant refactor, continuous build system etc<br />Doesn’t restricts upfront design when needed<br />
Motivation<br />If you intend to test after you‘ve developed the system, you won‘t have the time for testing.<br />If things get complicated, you might fear that, the system doesn‘t work.<br />If you‘re overwhelmed by the complexity, you get frustrated.<br />If you don‘t have tests for the code, you shouldn‘t use it / ship it.<br />If performance is only considered late, you won‘t be able to just, add a little more performance to the system.<br />
The TDD Methodology<br />RED - Write a test that defines how you think a small part of the software should behave. It will fail as the functionality doesn't exists at this point of time<br />GREEN - Make the test run as easily and quickly as you can. Don't be concerned about the design of code, just get it to work.<br />REFACTOR - Clean up the code. Now that the code is working correctly, take a step back and re-factor to remove any duplication or any other problems that were introduced to get the test to run.<br />
Benefits<br />The test is the executable specification.<br /><ul><li>You start thinking about the goal first, then about the possible implementations.
You understand the program‘s behavior by looking at the tests. The tests tell you more than just an API description, they show the dynamics, how to use the API.</li></ul>You develop just enough.<br /><ul><li>You get to the goal as quick as possible.
There is no test without a user requirement.</li></ul>Once you get one test working, you know it is working now and forever.<br /><ul><li>You use the tests as regression tests.</li></ul>The tests give us the courage to refactor.<br /><ul><li>You can prove that everything still works after the refactoring by simply executing the tests.</li></li></ul><li>How?<br />Don‘t start with objects (or design, or ...), start with a<br />test.<br />Write new code only if an automated test has failed.<br />First think of the goal, the required functionality.<br />Then think of the perfect interface for that operation (from the outside, black-box view).<br />Run the test often – very often.<br />To determine whether you‘ve reached the goal.<br />To catch any bugs that have crawled back in.<br />Make little steps (during coding and refactoring)<br />So little that you feel comfortable with them.<br />Make them larger if you feel.<br />Make them smaller if you don‘t proceed with your expected<br />velocity.<br />
Patterns for TDD<br />Testing Patterns<br />Red Bar Patterns<br />Green Bar Patterns<br />Refactoring<br />
Vulnerabilities<br />I think TDD is very difficult and involves lots of discipline .<br />It doesn’t prevent developers from implementing the wrong solution if they don’t understand the business problem to begin with, but it does help to ensure that the code you do write works the way you intended it to and is tested<br />Difficult to use in situations where full functional tests are required to determine success or failure. Like UI, programs work with DB, specific network configuration<br />Management support is essential.<br />Same developer will write test cases and Actual code – test may share the same blind spots with the code<br />High # of unit tests passing – can lead to less activities like Integration Testing, Devo testing etc.<br />