Test Driven Development

Test Driven Development

Transcript

1. Test Driven Development by Satya Sudheer
2. Before We Start! 4 There is just Code; there is no good or bad. 4 Everything we are going to discuss is already known to you! 4 Using automated feedback loops doesn't mean no manual testing. 4 Most of them are subjective, also debatable ..
3. Agenda 4 Basics 4 Test Driven Development 4 Coding Kata 4 TDD Pitfalls 4 Q&A
4. Testing 4 Testing is an act of gaining insights. 1. Is the app is usable. 2. Whats the user experience like? 3. Does the workflow make sense?
5. Verification 4 Verification, on the other hand, is an act of confirmation. 1. Does the code do what it's supposed to do? 2. Are the calculations right? 3. Regression, is the program working as excepted after the code or config. changes?
6. Do manual testing to gain insights and automated versification to influence the design and to confrim the code continues to meet the excpetations.
7. What is a "Unit Test" "it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing." - Martin Fowler A unit can be a method, function, class, group of classes.
8. Why Do We Write Unit Tests? 4 Validate the System, Immediate Feedback 4 Code Coverage 4 Enable Refactoring 4 Document the System Behavior 4 Your Manager Told You To
9. How many unit test do you write? public bool IsLoginSuccessful(string user, string password) { // ... } As part of that, we will do 4 State Verification 4 Behaviour Verification
10. Unit tests isolate the unit of work from its real dependencies, such as time, network, database, threads, random logic, and so on. Unit Tests runs in memory & quick!
11. Sociable Unit Test 4 Sociable unit testing covers more functionality, easier to maintain, but harder to debug.
12. Solitary Unit Test 4 Solitary unit testing enables higher code coverage, promotes decoupling; executes faster than sociable unit testing and enables better software designs.
13. What is a Boundary? A boundary is "a database, a queue, another system, or even an ordinary class. if that class is 'outside' the area your trying to work with or are responsible for" -- William E. Caputo
14. Solitary unit testing motivates us towards pure functions while allowing us to keep the benefits of OOP.
15. Test Doubles (Stunt Double) 4 Dummy, just used to fill parameter lists. 4 Fake objects actually have working implementations. 4 Stubs provide canned answers to calls made during the test. 4 Spies are stubs that also record some information. 4 Mocks are objects pre-programmed with expectations.
16. Test Pyramid? Its essential point is that you should have many more low-level unit tests than high level end-to- end tests running through a GUI. In short, tests that run end-to- end through the UI are: brittle, expensive to write, and time consuming to run.
17. Agile Testing Quadrants 4 Quadrant 1: Technology-facing tests that support the team 4 Quadrant 2: Business-facing tests that support the team 4 Quadrant 3: Business-facing tests that critique the product 4 Quadrant 4: Technology-facing tests that critique the product
18. Why Do We Write Unit Tests? [Revisting]
19. To find "Bugs" quickly. What if your "Unit Test" has bugs!
20. We need processes to help us do things well. 4 Algorithms help you do arithmetic. 4 Test Driven Development (TDD) helps you write software. 4 Solitary Unit Testing helps you write well designed software.
21. Test Driven Development Red - Green - Refactor Test-driven development (TDD), is a rapid cycle of testing, coding, and refactoring.
22. TDD is Not New! 4 1960: NASA used a similar process in project Mercury. 4 1994: Simple Smalltalk testing (SUnit) 4 1999: eXtreme Programming by Kent Beck 4 2002: TDD by Example by Kent Beck
23. TDD Cycle Red - Green - Refactor 4 Write a failing test for the next bit of functionality. 4 Write the functional code until the test passes. 4 Refactor both new and old code. TDD is not about "Testing", its more about "Development".
24. We rarely have trouble writing code, but they find it extremely hard to write tests before writing code. The nature and complexity of code widely affects the ability to write and run automated tests
25. Prepare to Experince Awesomeness! FizzBuzz Kata (TDD)
26. FizzBuzz 4 Write a program that prints the numbers from 1 to 100. 4 For multiples of three print “Fizz” instead of the number 4 For the multiples of five print “Buzz”. 4 For numbers which are multiples of both three and five print “FizzBuzz”.
27. Noodle Break, Not Exactly! Git Help 4 Fork & Getting Started git clone <url> cd kata 4 Sync with remote repo git pull origin master 4 Adding files: git add . git commit -m "appropriate message" git push origin master
28. "Unit Test" Frameworks 4 To Write Tests: Provides you an easy way to create & organize Tests. 4 To Run Tests: Allows you to run all, or a group of tests or a single test. 4 Feedback & Intergration: Immediate "Pass"/"Fail" feedback. Examples: MSUnit, JUnit, etc..
29. Canary Test Start with a "Canary Test". Its the simplest test you write to make sure your good with the code setup.
30. TDD: Step 1 Write a "Failing Test"
31. How to Write Super Awesome "Unit Tests" 4 Name - 3 Parts 4 Unit Of Work 4 Scenario 4 Expected behaviour 4 Structure - 3 "A"s 4 Arrange 4 Act 4 Assert
32. Do's & Dont's! 4 Zero logic 4 One assertion per test. 4 DAMP, not DRY 4 Write "Solitary", avoide Social Tests! 4 Don’t use variables, constants and complex objects in your assertions, rather stick with literals.
33. TDD: Step 2 Just code enough to "Pass the Test"
34. How to make a Test "Green"? 1. Fake It: Return a hard coded value, replace the hard coded values with variables; until the real code exits. 2. make It: Real code implementation, if it is immediately obvious. 3. Triangulate: Generalize code, when there are two or more
35. Super Simple "Tip" 4 Take Baby Steps: 4 Rule 1: The next step to take should always be as small as possible. 4 Rule 2: Read "Rule 1" - Yes, as small as possible.
36. Why Baby Steps? We will produce well-designed, well-tested, and well-factored code in small, verifiable baby steps.
37. TDD: Step 3 Improve the code by "Refactoring".
38. Oh, Yeah Refactoring 4 No "Logic Changes", Just moving the code around! 4 Explore performant code options. 4 Keep watching your "Unit Tests" 4 Remember "Baby Steps" Rule.
39. Refactoring is Important! The most common way that I hear to screw up TDD is neglecting the third step. Refactoring the code to keep it clean is a key part of the process, otherwise you just end up with a messy aggregation of code fragments.
40. Its Treasure .. Treat them as important as production code because they allow you to make changes confidently and correctly, improving your flexibility and maintainability over time.
41. TDD Benefits For Business 4 Requirement Verification 4 Regression Catching 4 Lower Maintenance Costs
42. TDD Benefits For Developers 4 Design First 4 Avoiding Over-Engineering 4 Momentum/ Developer Velocity 4 Confidence
43. TDD Pitfalls 4 Coverage as a goal. 4 Not recognising what phase you’re in. 4 Too many end-to-end tests. 4 Too much noise, not enough signal. 4 Not listening to the tests. 4 Not tackling slow tests. 4 Leaving broken tests.
44. "TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be bad design." - Kent Beck
45. Questions (if any)
46. The basic steps of TDD are easy to learn, but the mindset takes a while to sink in. Until it does, TDD will likely seem clumsy, slow, and awkward. Give yourself two or three months of full-time TDD use to adjust.
47. Coding Dojo To Become Awsome Developer
48. Suggested Reading
49. Image Credits 4 Dreamworks 4 Martin Flower Bliki Blogs 4 Martin Flower 4 James Shore
50. Content Reference 4 Test-Driving JavaScript Applications by Venkat Subramaniam
51. Thank You :)