Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(automatic) Testing: from business to university and back

326 views

Published on

This talk cares about the fundamentals of testing, a little bit history of how the professional community developed what we currently know as testing, but also about why I should care about testing? why is it important to do a test? What is important to test? What is not important to test? How to do testing?

There some examples in plnker just to see each step, and many surprises.

This talk also compares what people learned in the Computer Sciences and Engineering degrees and what people does in testing. It gives some tips to catch up with current state of art and gives some points to start changing syllabus to make better engineers.

This talk is good for beginners, teachers, bosses, but also for seasoned techies that just want to light up some of the ideas that they might have been hatching.

Spoiler alert: testing will save you development time and make you a good professional.

Published in: Software
  • Be the first to comment

  • Be the first to like this

(automatic) Testing: from business to university and back

  1. 1. (automatic) Testing from business to university and back David Ródenas — @drpicox
  2. 2. from business…
  3. 3. History
  4. 4. @drpicox 4 “The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel 1957 1979 1983 1988 Debugging Demonstration Destruction Evaluation Prevention mixing construction and debugging making sure that software satisfies its specification detecting implementation faults detecting requirements, design & implementation faults preventing requirements, design & implementation faults
  5. 5. @drpicox 5 “The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel “
  6. 6. @drpicox 6 http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment 1994 1999 2002 Beginning of new Era xUnit Extreme Programming Framework Integrated Test Test Driven Development Ward Cunningham writes in one day a test runner Kent Beck writes first version of SUnit (Testing Framework) “Extreme Programming Explained: Embrace Change” - Kent Beck Ward Cunningham writes first tool for test running “Test Driven Development By Example” - Kent Beck 1989
  7. 7. @drpicox Testing Tools • NUnit, MSTest, …— C# • FUnit, FRUIT, FortUnit, …— Fortran • JUnit, FitNesse, Mockito, …— Java • Jasmine, Mocha, QUnit, …— Javascript • Unittest, py.test, Nose, …— Python • MiniTest, Test::Unit, RSpec, … — Ruby • … • Cucumber, Selenium, SpecFlow, …— Scenario 7
  8. 8. @drpicox Testing Tools describe(‘calculator’, () => {
 it(‘should do sums’, () => { let calculator = new Calculator(); calculator.input(2); calculator.plus(); calculator.input(4); calculator.equal(); let result = calculator.get(); expect(result).toBe(6); }); … }); 8
  9. 9. @drpicox Testing Tools 9 2,4,8 Rule Game http://embed.plnkr.co/N0eGMg
  10. 10. Why testing?
  11. 11. @drpicox Coding cost 11 +- +- Think Write Debug +-
  12. 12. @drpicox Coding cost 12 Think +- • Surrounding code • API for the new code • Understand new features
  13. 13. @drpicox Coding cost 13 Write +- • Faster typist speed is: 150 wpm • Moderate typist speed is: 35 wpm • 400 line code may contain 1000 words ~ 30 minutes
  14. 14. @drpicox Coding cost 14 Debug +- • Even if everything works well, we have to verify that it is true • Navigate to affected point • Make sure that everything works as expected, each time • If it fails, stop and start looking for problems…
  15. 15. @drpicox Coding cost 15 Debug +- ¿How many debug cases have you thrown away?
  16. 16. @drpicox Coding cost 16 +- +- Think Write Debug +-
  17. 17. @drpicox Coding cost 17 +- +- Think Write Debug +-
  18. 18. @drpicox Coding cost 18 +- +- Think Write Debug +-
  19. 19. @drpicox Why testing? 19
  20. 20. @drpicox Why testing? • Automatic testing saves time
 • Considers all features with all semantics • Everything is debugged • Does not throw away debug cases • New features does not break old one • Safe refactors to accommodate new changes • More bald implementations
 • Developers(professionals) feel safer. 20
  21. 21. What to test?
  22. 22. @drpicox Types of bugs 22 Logic Wiring Visual
  23. 23. @drpicox Types of bugs 23 Logic Wiring Visual Detection Diagnose Correction
  24. 24. @drpicox Types of bugs 24 Logic Wiring Visual Detection HARD EASY TRIVIAL Diagnose HARD MEDIUM EASY Correction HARD MEDIUM EASY
  25. 25. @drpicox Detection HARD MEDIUM EASY Diagnose HARD MEDIUM EASY Correction HARD MEDIUM EASY Types of bugs 25 Logic Wiring Visual It is hard! Is it?
  26. 26. @drpicox Types of testing 26 Logic Wiring Visual #tests whole system subsystems just classes each takes
  27. 27. @drpicox Types of testing 27 Logic Wiring Visual > 10s < 1s ~1ms few many lots end-to-end functional unit known as whole system subsystems just classes #testseach takes
  28. 28. @drpicox Types of testing 28 Logic Wiring Visual > 10s < 1s ~1ms each takes few many lots end-to-end functional unit known as whole system subsystems just classes acceptance testing bdd tdd #tests
  29. 29. @drpicox Types of testing 29 Logic Wiring Visualwhole system subsystems just classes Unit End- -to-End Functional SoftwareEngineers QAEngineers
  30. 30. @drpicox Unit Testing • It test the most dangerous kind of bugs • It is easy to write • It is fast to execute • It is from engineers to engineers • It focus into features details 30
  31. 31. @drpicox Unit Testing • It test the most dangerous kind of bugs → Solves them • It is easy to write → Write tens in few minutes • It is fast to execute → Development cycle of seconds • It is from engineers to engineers → It is the doc • It focus into features details → Solve fast ambiguity • IT IS THE MOST POWERFUL TYPE OF TESTING 31
  32. 32. @drpicox Unit Test Everything! • Test coverage? 32
  33. 33. @drpicox Unit Test Everything! • Test coverage? 33 ¿Are you sure that you want to write a line of code that cannot be justified with a test? ¿Do you want to write useless code? ¿Do you want to maintain more code than necessary? ¿Do you want to relay in your ability to manual testing all cases?
  34. 34. @drpicox Unit Test Everything! 34 Serious Banking http://embed.plnkr.co/veOMnl 🃏
  35. 35. @drpicox Unit Test Everything? 35 Serious Banking http://embed.plnkr.co/veOMnl 🃏 Sorry, not everything, we have frame problem. (we can imagine infinite stupid things that can go wrong)
  36. 36. @drpicox TDD Rules 36 • Has anyone tried to write tests after write the code?
  37. 37. @drpicox TDD Rules 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 37 http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  38. 38. @drpicox TDD Rules 38 • You can see it in the following Kata: • The Bowling Game Kata
  39. 39. …crossing to university
  40. 40. @drpicox Verification 40 // Pre: 0 ≤ left ≤ right ≤ vec.length function posMin(vec, left, right) { let pos = left; for (let i = left + 1; i <= right; i++) { if (vec[i] < vec[pos]) pos = i; } return pos; } // Post: returns pos ∧ // ∧ left ≤ pos ≤ right ∧ // ∧ vec[pos] = min(vec[left … right])
  41. 41. @drpicox Automatic Evaluation 41 $ cc my-solution.c -o my-solution $ diff <(./my-solution < p1.in) p1.out
 $ diff <(./my-solution < p2.in) p2.out
 $ diff <(./my-solution < p3.in) p3.out
 $ diff <(./my-solution < p4.in) p4.out $ cp my-solution.c /home/subject/e/h8463827.c
  42. 42. @drpicox Patterns • Abstraction factory • Builder • Factory method • Prototype • Singleton • Adapter • Bridge 42 • Composite • Decorator • Facade • Proxy • Chain of responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template method • Visitor
  43. 43. @drpicox Grasp • Controller • Creator • High cohesion • Indirection • Expert 43 • Low coupling • Polymorphism • Protected variations • Pure fabrications
  44. 44. @drpicox Designs 44
  45. 45. what else should be there?
  46. 46. @drpicox Hello World 46 describe(‘hello world’, () => {
 it(‘it should say hi there!’, () => { let helloWorld = new HelloWorld(); helloWorld.sayHello(); expect(???).toBe(‘hi there!’); }); }); http://embed.plnkr.co/JxAOX7
  47. 47. ban Singletons
  48. 48. ban Singletons Seriously no buts they lie they are evil ARE GLOBALS! i’ll got zero in 1st course if I've used them also ban class members
  49. 49. ban Singletons Seriously no buts they lie they are evil ARE GLOBALS! use singletons instead (^ yes, lowercased s) i’ll got zero in 1st course if I've used them also statics
  50. 50. @drpicox Dependency Injection function testCreditCardCharge() { CreditCard c = new CreditCard( "1234 5678 9012 3456", 5, 2008); c.charge(100); } 50 It gives as result: NullPointerException
  51. 51. @drpicox Dependency Injection function testCreditCardCharge() { Database.init(); CreditCardProcessor.init(); OfflineQueue.init(); CreditCard c = new CreditCard( "1234 5678 9012 3456", 5, 2008); c.charge(100); } 51 It works… but you loose 100$
  52. 52. @drpicox Dependency Injection function testCreditCardCharge() { Database db = new Database(); OfflineQueue q = new OfflineQueue(db); CreditCardProcessor ccp = new CreditCardProcessor(q); CreditCard c = new CreditCard( "1234 5678 9012 3456", 5, 2008); c.charge(ccp, 100); } 52 Looks better, right? But you still loosing 100$.
  53. 53. @drpicox Dependency Injection function testCreditCardCharge() { CreditCardProcessorMock ccp = new CreditCardProcessorMock(); CreditCard c = new CreditCard( "1234 5678 9012 3456", 5, 2008); c.charge(ccp, 100); assertTrue(ccp .charged("1234 5678 9012 3456", 100)); } 53 Looks better!
  54. 54. @drpicox Dependency Injection • Is inversion of control for resolving dependencies. • Your dependencies will explicitly be: • given by constructor
 
 
 
 • setted after construction 54 class UserController { constructor(userService) { this.userService = userService; } }
  55. 55. @drpicox Dependency Injection 55 Two piles Pile of Objects • Business logic • This is why you write code Pile of New Keywords • Factories, Providers, … • Build object graphs • This is how you get the code you write to work together new new new new new new new new new new new
  56. 56. @drpicox Dependency Injection 56 describe(‘hello world’, () => {
 it(‘it should say hi there!’, () => { let console = jasmine.createSpyObj(‘console’, [‘log’]); let helloWorld = new HelloWorld(console); helloWorld.sayHello(); expect(console.log).toHaveBeenCalledWith(‘hi there!’); }); }); http://embed.plnkr.co/vZyo7u
  57. 57. @drpicox Law of Demeter • You only ask for objects which you directly need (operate on) • a.getX().getY()… is dead giveaway • serviceLocator.getService() is breaking the Law of Demeter • Dependency Injection of the specific object you need. Hollywood Principle. 57
  58. 58. …and back to business
  59. 59. @drpicox How university can contribute? • Write tests First! • Create testing syllabus • Get deeper in Cohesion • Transmit: Professionalism require testing 59
  60. 60. @drpicox 60 Summary
  61. 61. @drpicox Sumary • Testing saves development time • Focus in Unit Test 
 (acceptance testing is also amazing) • Tests to show that your code is what you need • Make dependencies explicit 61
  62. 62. @drpicox Sumary • and of course: 62 Write tests First!
  63. 63. @drpicox Bibliography 63 • “The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel • http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment • https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 • https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073 • http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd • http://butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne • http://misko.hevery.com/2008/11/17/unified-theory-of-bugs/ • http://misko.hevery.com/2008/08/25/root-cause-of-singletons/ • http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ • http://misko.hevery.com/code-reviewers-guide/ • http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing • http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/ • http://butunclebob.com/ • http://misko.hevery.com/
  64. 64. @drpicox Bibliography 64
  65. 65. @drpicox Thanks! 65 David Ródenas — @drpicox

×