Agile Work Quality: Test Driven Development and Unit Tests
1 like186 views
The document discusses agile work quality with a focus on Test-Driven Development (TDD) and unit tests, highlighting the importance of iterative coding and testing. It outlines the role of strategic data systems and their services, including application development and agile coaching. Additionally, it explains the workflow of agile projects, detailing the breakdown of epics, features, and stories to improve software quality and testing practices.
Agile Work Quality: Test Driven Development and Unit Tests
- 1. Agile Work Quality: TDD and Unit Tests Keith Callis Principle Consultant, Strategic Data Systems [email protected]
- 2. About Keith Callis Principal Consultant at SDS, Inc., based in Cincinnati. Software developer. Scrum Master (Scrum Alliance). Current agile projects: (Pivotal Tracker) SQL Server conversions. (Rally) Hadoop, Oracle, MongoDB, Java, Scala. When not writing or breaking software, he is amateur photographer or chef in his kitchen.
- 3. Strategic Data Systems – What we do: We work with our customers to improve their business with technology. Our professional services include: Application Development and Application Renovations Architecture, Development, and Architectural Design Reviews .NET, Java Agility - Agile Coaching and Transformations Training - Agile, .NET Our place or yours! We are looking for .NET/Java developers, Scrum Masters and Product Owners.
- 4. Agile Work Flow • Epics • Features • Stories • Stories only • Backlog of stories
- 5. Epics • Work goal • Create Payroll system • New Web site for maintaining customer information • Add searching capability to existing web site
- 6. Features • Break down of an epic • Payroll system • Maintain staff • Add/Inactivate people • Change pay • Change deductions • Calculate payroll • Grose Pay • Deductions • Net Pay • Make payments • Paper checks • Direct deposit
- 7. Stories • Break down a feature • Calculate payroll • Gross pay • Hourly • Salaried • Overtime • Bonuses • Deductions • Pre-tax items • 401K • Insurance • HSA • Taxes • Federal • State • Local • SSN
- 8. Work a story • Description of the work • Ask for more information is not clear • Clear Condition of Acceptance for story • Ask for clarification if not clear or not known how to deliver • Attachments to story that may help • Spreadsheets with existing calculations
- 9. Time to Start Coding? • Should code “design” take place? • What code should be added? • Where should the code be added? • How to meet “conditions of acceptance” in story? • How to test new code? • Are there existing tests?
- 10. TDD • Write a Test • Run the Test • Test should Fail • Write just enough code for Test to pass • Run the Test • Test should Pass • Repeat
- 11. Write Test First @Test public void whenMonthly_thenReturnOneTwelfth() { Double yearlySalary = 12000.0; Double expected = 1000.00; Double actual = salaryCalculation.CalculateMonthlySalary(yearlySalary) ; Assert.assertEquals("Expected Monthly Salary not correct", expected, actual); }
- 12. Pure TDD • Missed first test • Should have a test that the class exists • Then go with the test for the method
- 13. Test Values @Test public void whenMonthly_thenReturnOneTwelfthRounded() { Double yearlySalary = 12002.0; Double expected =1000.17; Double actual = salaryCalculation.CalculateMonthlySalary(yearlySalary); Assert.assertEquals("Expected Monthly Salary not correct", expected, actual); } java.lang.AssertionError: Expected Monthly Salary not correct Expected :1000.17 Actual :1000.1666666666666
- 14. Code Change public double CalculateMonthlySalary(double annualSalary) { return annualSalary / 12; } ______________________________________________ public double CalculateMonthlySalary(double annualSalary) { return Math.round(100.0 * annualSalary / 12) / 100.0; }
- 15. Edit Code Again public SalaryCalculationImpl(double salary, double periods) { this.annualSalary = salary; this.periods = periods; } public void CalculateMonthlySalary() { this.salary = Math.round(100.0 * annualSalary / periods) / 100.0; }
- 16. Test Passes, Wrong Check @Test public void whenMonthly_thenReturnOneTwelfth() { Double yearlySalary = 12000.0; Double expected = 1000.00; salaryCalculation = new SalaryCalculationImpl(yearlySalary, 12); salaryCalculation.CalculateMonthlySalary(); Assert.assertNotNull("SalaryCalculation object not null", salaryCalculation); }
- 17. Test Passes, Better Check @Test public void whenMonthly_thenReturnOneTwelfth() { Double yearlySalary = 12000.0; Double expected = 1000.00; salaryCalculation = new SalaryCalculationImpl(yearlySalary, 12); salaryCalculation.CalculateMonthlySalary(); Assert.assertEquals("Expected Monthly Salary not correct", expected, salaryCalculation.getSalary(), 0); }
- 18. TDD Drive Code Design • As tests are written • Minimal code gets written • No extra/dead code gets written • New code added to pass new tests • Lowers chance for code that cannot be tested
- 19. No TDD, but Unit Tests • Write a little new code • Method • Class • Write tests for new code • Runs risk of not testing all paths of code
- 21. Code First, Test Later • Write most of program first • Try to write unit tests • Takes more time • Some code may not be able to be tested • Can result in less code coverage
- 22. Write Code, Toss Over the Wall • Write program • No tests • Let someone else test • QA tester • Not all paths tested • If test fails, harder to locate failing code
- 23. Unit vs Integration Tests • Unit test • Just code (class/method, maybe multiple classes) • No external resources (database, file) • Integration test • Code accessing external resources (database, file) • Harder to setup • Harder to validate results
- 24. Many Unit Tests • Allows more confidence when making changes to code • Example for new story for a found defect • Create new unit tests that fail • Update code for new unit tests to pass • Run ALL unit test to insure no impact on other areas of code
- 25. “Eat the dog food” • All unit tests pass for programs • However, issue when programs used in final system • Web site • Production data • Program being called by other programs
- 26. Handle Multiple Conditions • Example handling batches, e.g. batch size 100 • Unit test passes using value of 100 • Unit test fails using value of above or below 100 • Remember to handle multiple values with multiple unit tests • Zero • One • More than one • Null • Negative
- 27. Tests and Story’s COA • Depending on PO and COA and Story • One or two unit tests may allow story to be accepted • An integration test may allow story to be accepted
- 28. Story’s COA and Tests • Unit tests can be written for well written COA’s • This can drive out more details for story • More COA’s may be needed for found conditions • Original COA’s handled “good path” • Unit tests points out “invalid paths”
- 30. Test Early, Test Often image from https://brockbiv.wordpress.com