Download as PDF, PPTX
![A typical example
public class TestCalculator {
public static void main(String[] args) {
Calculator c = new Calculator();
double result = c.add(5, 6);
if(result != 11) {
System.out.println(“wrong result”);
}
// rest of the class omitted
}
}
public class Calculator {
public double add(double a, double b) {
return a + b;
}
public double sub(double a, double b) {
return a - b;
}
public double mul(double a, double b) {
return a * b;
}
public double div(double a, double b) {
return a / b;
}
}
Production Code
(System Under
Test)
Test Code](https://image.slidesharecdn.com/takeprideinyourcode-test-drivendevelopment-161229133414/85/Take-Pride-in-Your-Code-Test-Driven-Development-13-320.jpg)
![Writing tests with JUnit
import . . . // imports omitted
public class TestCalculator {
public static void main(String[] args) {
Calculator c = new Calculator();
double result = c.add(5, 6);
if(result != 11) {
System.out.println(“wrong result”);
}
// rest of the class if omitted
}
}
import . . . // different imports, omitted
public class TestCalculator {
@Test
public void addTwoNumbers_ReturnsSum() {
Calculator c = new Calculator();
double result = c.add(5, 6);
assertEquals(21, result);
}
}](https://image.slidesharecdn.com/takeprideinyourcode-test-drivendevelopment-161229133414/85/Take-Pride-in-Your-Code-Test-Driven-Development-21-320.jpg)
Uploaded byBADR
Take Pride in Your Code - Test-Driven Development
The document outlines principles and practices of test-driven development (TDD) in software engineering, emphasizing the importance of self-testing code and its benefits, such as improved design, easier bug detection, and long-term time savings. It covers various exercises to implement TDD, introduces various coding examples and frameworks, and promotes discussion around the impact of testing on software quality. The session encourages developers to embrace TDD as a way to produce high-quality, maintainable code while fostering confidence and enjoyment in programming.
More Related Content
Similar to Take Pride in Your Code - Test-Driven Development
Take Pride in Your Code - Test-Driven Development
- 2. Take pride inyour code Test-Driven Development
- 3. Credits Ahmed HammadAmeer Gaafar Disclaimer:The content and structure of this slides is based on the presentation Ameer and Ahmed authored.
- 4. Introductions first! ● Iam ⚪ Ahmed Moawad ⚪ CSD 2009 ⚪ Software Engineer ⚪ Chief Operating Officer at BADR ⚪ @ ahmed.moawad@badrit.com ⚪ in /ahmedmoawadibraheem ● Who are you?!
- 5. Expectations? What do youthink this, considerably long, session is about?!
- 6. So, it’s notabout: ● Test first. ● Unit testing. ● Testing! Surprisingly, it’s about design :D
- 7. Logistics ● 50 minutessprints, 10 minutes break. ● Be on time. ● Cell phones SILENT. ● Feel free to: ⚪ Speak up. ⚪ Discuss. ⚪ Sit in groups, form teams. ⚪ Mingle, move around, go out and come back (but QUIETLY)
- 8.
- 9.
- 10. Traditionally ● How muchdo you code before your test? ● How do you test? ● How do you find bugs? Code Compile Test Fix bugs
- 11. The debugger curve(uncle Bob’s* claim!) Debugging Skills Productivity * Robert Martin
- 12. Testing Code, withcode! Move coding into an emotional state! Take pride! Love what you do! Have fun!
- 13. A typical example publicclass TestCalculator { public static void main(String[] args) { Calculator c = new Calculator(); double result = c.add(5, 6); if(result != 11) { System.out.println(“wrong result”); } // rest of the class omitted } } public class Calculator { public double add(double a, double b) { return a + b; } public double sub(double a, double b) { return a - b; } public double mul(double a, double b) { return a * b; } public double div(double a, double b) { return a / b; } } Production Code (System Under Test) Test Code
- 14. Self-Testing Code Write CodeCompile Write Test Code Make tests pass Run Tests Compile Test Code
- 15. Self-Testing Code By theprogrammers, for the programmers Programmers take responsibility of quality
- 16. Impact on Code ●Smaller pieces ● Separation of concerns ● Easier to test ● Easier to modify Regression testing becomes almost free! Loose coupling Iff you use good names Solid system (not fragile)
- 17. More benefits oftests ● Documentation of code. ⚪ Living, executable documentation. ● Catch future defects. ⚪ You have a safety net. ● Long-term time saving. ⚪ You know when something is broken before deployment. But testing is merely a tool, it not the process.
- 18. Now what? What doyou think will/should happen to the test code?
- 19. xUnit Family ● Frameworksfor writing programmer tests ● Integrated with IDEs and build environments ● Exist for virtually all programming languages and environments It’s not about units, it’s about self-testing code
- 20.
- 21. Writing tests withJUnit import . . . // imports omitted public class TestCalculator { public static void main(String[] args) { Calculator c = new Calculator(); double result = c.add(5, 6); if(result != 11) { System.out.println(“wrong result”); } // rest of the class if omitted } } import . . . // different imports, omitted public class TestCalculator { @Test public void addTwoNumbers_ReturnsSum() { Calculator c = new Calculator(); double result = c.add(5, 6); assertEquals(21, result); } }
- 22. What it lookslike in real life :) Test cases Coverage Success Production code Test code
- 23. Environment Setup Exercise Enoughtalking, let’s power up those machines
- 24. Temperature conversion ℃ ×9/5 + 32 = ℉ (℉ - 32) × 5/9 = ℃
- 25.
- 26. Tennis Scoring System Player1 Player 2 Score ⬤ Fifteen - Love ⬤ ⬤ Fifteen - Fifteen ⬤⬤ ⬤ Thirty - Fifteen ⬤⬤⬤ ⬤ Forty - Fifteen ⬤⬤⬤⬤ ⬤ Game, Player 1 ⬤⬤ ⬤⬤⬤ Thirty - Forty ⬤⬤⬤ ⬤⬤⬤ Deuce ⬤⬤⬤⬤ ⬤⬤⬤ Advantage, Player 1 ⬤⬤⬤⬤ ⬤⬤⬤⬤ Deuce ⬤⬤⬤⬤ ⬤⬤⬤⬤⬤ Advantage, Player 2 ⬤⬤⬤⬤ ⬤⬤⬤⬤⬤⬤ Game, Player 2
- 27. Benefits of self-testingcode? ● Executable proof of quality ● Free regression test ● Inspires confidence ● Reduces cost of change Bonus :D A formal proof! It doesn’t get more formal than that!! Added cost to development time is about 50%, BUT, it’s worth the investment
- 28. “Never in thefield of software development have so many owed so much to so few lines of code.” Martin Fowler
- 29. Discussion ● So, whatis the ‘unit’ in xunit? ⚪ Class? ⚪ Method? ⚪ Component? Interesting behavior
- 30. There ought tobe some boring stuff here about SUT, DOC and Isolation! System Under Test Depended-on Object
- 31. Leap Year Exercise booleanleapYear(int year) A leap year is defined as one that is divisible by 4, unless it’s divisible by a 100, in which case, it should also be divisible by 400. Lear Years: 1996, 2000 Common Year: 2001, 1900
- 32. Test-Driven Development Yes, upto this point, we didn’t speak off TDD yet :D
- 33. Traditionally Code Compile Test Fixbugs Write Code Compile Write Test Code Make tests pass Run Tests Compile Test Code
- 34. TDD Write a test See itfail Make it pass Make it better Establish expectations Single test Failure is progress Using the simplest solution, even if ugly Now improve the design guarded with tests and better understanding Refactor
- 35. Now, to the1st live TDD session The Bowling Kata
- 36. ... but beforewe dig in Red (test) Green (make it pass) Refactor
- 37. The Bowling Kata ●10 frames per game, up to 2 attempts per frame ● All pins down from 1st attempt (strike) ⚪ Frame is over, Score is 10 + score the next two balls ● All pins down in the two balls of the frame (spare) ⚪ Score is 10 + score if the next ball ● Less than 10 down in two balls of the frame ⚪ Score is number of pins down ● Spare in the 10th frame? ⚪ One bonus ball ● Strike in the 10th frame? ⚪ Two bonus balls
- 38. Bowling score calculatordesign + rolls(pins : int) + score(): int Game + score(): int Frame - pins: int Roll Tenth Frame 10 1..2 1 Next frame INITIAL DESIGN
- 39. The Bowling Kata So,how did you find it?
- 40. TDD Benefits All testingbenefits + ● Consumer focused, simple design ● Just enough code to meet expectations (lean) ● No untested code
- 41. Now, it’s yourturn Your first TDD program
- 42. Standard deviation Write aprogram that prints the standard deviation of the a series of a population of numbers.
- 43. ... but beforeyou dig in! Remember ● You’re learning a technique, not solving a problem ● Baby steps ● Failing tests first ● Just enough code to pass the test ● Keep it clean
- 44. FizzBuzz Kata Write aprogram that prints the numbers from 1 to 100, BUT: ● For multiples of three, print “Fizz” ● For multiples of five, print “Buzz” ● For multiples of both, print “FizzBuzz”
- 45. Roman Numerals Kata ConvertArabic numbers to Roman: 1 -> I 2 -> II 3 -> III 4 -> IV 5 -> V 6 -> VI 7 -> VII 8 -> VIII 9 -> IX 10 -> X 20 -> XX 30 -> XXX 40 -> XL 50 -> L 60 -> LX 70 -> LXX 80 -> LXXX 90 -> XC 1000 -> M 2000 -> MM 3000 -> MMM 100 -> C 200 -> CC 300 -> CCC 400 -> CD 500 -> D 600 -> DC 700 -> DCC 800 -> DCCC 900 -> CM 1990 = MCMXC 99 = XCIX 2008 = MMVIII 47 = XLVII
- 46. Prime Factors Kata Printthe prime factors of an arbitrary number 1 -> { } 2 -> { 2 } 6 -> { 2, 3 } 12 -> { 2, 2, 3 } 14 -> { 2, 7 } 286 -> { 2, 11, 13 }
- 47. Test smells ● Obscuretest ● Conditional test ● Hard-to-test code ● Test code duplication ● Test logic in production ● Assertion roulette ● Erratic test ● Fragile test ● Frequent debugging ● Manual intervention ● Slow test Code Smells Behavior Smells
- 48. Unit testing SweetSpot ● Fast executing. ● Independent. ● Large number. ● Narrow in focus. ● Simple in structure. ● Easy to setup and teardown.
- 49. Further considerations ● Differenttest runners (Jasmine default, Karma, ...) ⚪ Why? ● Impact on development time. ⚪ Usually, people would tell you it’s a 50% tax. ⚪ Usually, it’s not true :D. ● Code coverage. ● Data providers. ● Mocks and stubs.
- 50. Conclusion ● Simple !=Easy. ● You have to master the craft to reap the fruit. ● The art of fearless programming. ● Programming, enjoyable again. ● The dream of executable requirements. ● Towards a better design for software. ● A hope for the lost souls. Other possible titles! All code is guilty until proven innocent All code is legacy unless it has tests
- 51. Thank you! I hopeyou enjoyed this class