Advertisement
Advertisement

More Related Content

Advertisement

Recently uploaded(20)

Software Quality via Unit Testing

  1. SOFTWARE QUALITY VIA UNIT TESTING Shaun Abram April 20, 2013 Email: Shaun@Abram.com Blog: shaunabram.com Twitter: @shaunabram LinkedIn: linkedin.com/in/sabram These slides available at shaunabram.com/dcc13
  2. 2 Software Quality via Unit Testing The value of software design Automated testing Clean code Goal: Deliver value to our users
  3. 3 Software Quality via Unit Testing The value of software design
  4. 4 Why should we care about „good‟ design in software? We need less focus on quality so we can add more features Do we really need unit tests? Refactoring doesn‟t change what the code does, so why bother? How do you respond?
  5. 5 Why should we care about „good‟ design in software? Take the moral high ground?
  6. 6 Why should we care about „good‟ design in software? We need to have economic reasons Remember: Our goal is to deliver value to our users
  7. 7 What is Quality in software anyway? Intuitive GUI Few defects Modular Design
  8. 8 What is Quality in software anyway? Intuitive GUI Few defects Visible to user Modular Design Transparent to user
  9. 9 Fowler‟s Design Stamina Hypothesis
  10. 10 Technical debt The eventual consequences of poor design in a codebase
  11. 11 Technical debt The eventual consequences of poor design in a codebase Interest payments can come in the form of: 1. Bugs 2. Just understanding what the heck the current code does 3. Refactoring 4. Completing unfinished work
  12. 12 Technical debt Pay down? Accept? But, don‟t build bad on top of bad…
  13. Design Stamina Design stamina to continually and consistently deliver functionality faster and with less bugs to our users Business value to our clients
  14. 14 Clean code that works • The value of software design • Automated testing
  15. 15 Unit testing A unit test is a piece of code that executes a specific functionality („unit‟) in the code, and • Confirms the behavior or result is as expected. • Determines if code is „fit for use‟ Example…
  16. 1
  17. 1
  18. 1
  19. 1
  20. 2
  21. 2
  22. 2
  23. 2
  24. 25 What unit tests provide Unit tests don‟t necessarily help find bugs. Instead, unit tests: • Drive design
  25. 26 What unit tests provide Unit tests don‟t necessarily help find bugs. Instead, unit tests: • Drive design • The tests act as the first user of the code, making you think about: • What should this code do • Border conditions (0, null, -ve, too big) • Force you to use good design: • Short, focused methods • Dependency Injection • Writing a class is different from using a class!
  26. 27 What unit tests provide Unit tests don‟t necessarily help find bugs. Instead, unit tests: • Drive design • Act as safety buffers by finding regression bugs • Provide documentation
  27. 28 What unit tests provide Unit tests don‟t necessarily help find bugs. Instead, unit tests: • Drive design • Act as safety buffers by finding regression bugs • Provide documentation Can also be used on legacy codebases
  28. 29 Unit testing limitations 1. Can not prove the absence of bugs 2. Lot‟s of code (x3-5) 3. Some things difficult to test
  29. 30 So should we unit test? Not only should we unit test, We should let unit tests drive development and design… Test Driven Development (TDD)
  30. 31 Test Driven Development (TDD)
  31. 32 Test Driven Development (TDD)
  32. 33 Test Driven Development (TDD)
  33. 34 Test Driven Development (TDD) Red - Green – Refactor: the TDD Mantra No new functionality without a failing test No refactoring without passing tests
  34. 35 Test Driven Development (TDD) Example Write a simple StringCalculator class with a method Integer add(String numbers) A String of comma separated numbers should return their sum e.g. “1,2,10” should return 13. A single number String should return that number e.g. “3” should return 3 An empty String should return 0 For brevity, our test will focus on valid inputs.
  35. 36 Test Driven Development (TDD) Example Write a simple StringCalculator class with a method Integer add(String numbers) Code demo…
  36. 3
  37. Refactor?
  38. Refactor?
  39. These tests act like the original developer looking over your shoulder and advising you, long after that developer has left…
  40. 58 Test Driven Development (TDD) Red - Green – Refactor: the TDD Mantra No new functionality without a failing test No refactoring without passing tests
  41. 59 Clean code that works • The value of software design • Automated testing
  42. 60 Clean code that works • The value of software design • Automated testing • Clean code
  43. 61 • Feedback… • XKCD
  44. 6
  45. 63 Code Smells What are code smells? “Certain structures in code suggest (sometimes they scream for) the possibility of refactoring.” Martin Fowler. Refactoring: Improving the design of existing code
  46. 64 Code Smells • Duplicated code • Long switch/if statements • Long methods Even one line methods can be OK: if ( (account != null) && ( (account.getBalance() > 0) || (!account.overdraftLimitReached()) ) { … } if (account.hasFundsAvailable()) { … }
  47. 65 Code Smells • Duplicated code • Long switch/if statements • Long methods • Poor method names int process(int id) { //bad! int calculateAccountBalance(int accountID) { //better
  48. 66 Code Smells • Duplicated code • Long switch/if statements • Long methods • Poor method names • In-line comments • Large classes • Symptoms • Too many methods (>10 public?) • Too many instance variables – is every instance variable used in every method? • Solutions • Eliminate redundancy / duplicated code • Extract new/sub classes
  49. 67 Clear Code Make the intent of your code clear Code should be clear, concise and easy to understand How many times will the code you are about to write be read? Studies show poor readability correlates strongly with defect density1 Avoid attrition & complete re-writes 1"Learning a Metric for Code Readability," IEEE Transactions on Software Engineering, 09 Nov. 2009. IEEE computer Society Digital Library. IEEE Computer Society
  50. 68 Summary • Good design gives us the stamina to continually and consistently deliver business value • Unit tests are an integral part of good design; TDD is even better • Good design can also simply be cleaner code; Aggressively refactor to achieve this! Final thought: Every time you are in a piece of code, just make one small improvement!
  51. 69 Recommended Reading Test Driven Development Growing Object-Oriented Kent Beck Software, Guided by Tests Freeman & Pryce Refactoring: Improving the Design Effective Unit Testing of Existing Code Lasse Koskela Martin Fowler, Kent Beck et. al.
  52. Questions? All slides available at: shaunabram.com/dcc13 Email: Shaun@Abram.com Blog: shaunabram.com Twitter: @shaunabram LinkedIn: linkedin.com/in/sabram 7
Advertisement