Test Driven Development (TDD) Basics

68 views

Published on

Presentation about TDD on the GDCR 2016 event organized at the ThoughtWorks South Africa offices

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
68
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Design:
    * We normally rush to start coding a solution without thinking much about the problem itself.
  • Exact functionality:
    *
  • Examples:
    Traditionally we will code based on use cases that describe the functionality with natural language.
    Most of the times there is ambiguity expressed on them because of our language.
    The idea is to generate as much examples as needed in order to remove all the ambiguity.

    Architecture:
    Will emerge at a higher level.
    Depends on the type of application we are implementing and the technologies we are using.
    Not that we should not think on architectural decisions or concerns, but we will postpone them until they are necessary.
    Normally we design applications having several layers, transfer objects, factories and so on, but we may not need them.
    Freedom to the developer. In some contexts, all has to be coded the same way.

  • Red
    We’ll start writing a test for a certain example.
    Why?
    Compilation errors
    Test failures

    Green
    We’ll implement the minimum possible functionality to cover the test case.
    We’ll be tempted to write a bit more code. We should be strong.

    Refactor
    We’ll revisit our test and implementation code to see if we can improve something without changing the functionality.
    What can we do?
    Clean the code
    Extract variables,
    Reduce duplication
    We should try to improve something, at least a bit. Sometimes it won’t be obvious, but we should spend a bit of time trying to refactor.
  • What does email validation mean for this specific context?

    The fact is that validating an email, although sounds universal, may be very specific depending on the business context.
  • To write tests we need some technology support, which is presented as a Testing Framework.
    Some languages and frameworks include some kind of unit testing support, such as …
    But in any case there are several unit testing frameworks we can use to write tests for our code, even if the language does provide some testing support.
    Just to name a few
    Java
    .NET
    JavaScript

  • We’d like to refactor, but the code is so tiny…
  • We’d like to refactor, but the code is so tiny…
  • We’d like to refactor, but the code is so tiny…
  • We’d like to refactor, but the code is so tiny…
  • Test Driven Development (TDD) Basics

    1. 1. Test Driven Development
    2. 2. Test Driven Development  Technique to design and develop software.  Practice part of the Extreme Programming methodology — XP  Based on three fundamental pillars.
    3. 3. TheThree Pillars  Implement the exact functionality of the software.  Reduce the number of defects on the software – good quality software  Produce modular and highly reusable software.
    4. 4. When Doing TDD  It’s not about just writing tests.  Translate use cases to examples.  Enough to describe the functionality without ambiguity.  Architecture will eventually emerge.
    5. 5. TheTDD Algorithm Red GreenRefactor
    6. 6. TheTDD Algorithm Red GreenRefactor
    7. 7. TDD InAction With an example ;-)
    8. 8. The Problem Email validation mechanism
    9. 9. The Problem Email validation mechanism
    10. 10. The Problem Email validation mechanism Neither empty nor null. Has to contain an @ symbol Has to belong to the .com, .net and .eduTDLs Domain part can’t be 1 character long All lowercase Not contain numbers Only _ . - symbols
    11. 11. Before we begin WritingTests  Testing framework  Part of the language  Ruby  Rust  Go  Python  External tools and libraries TestNG MSTest
    12. 12. Neither empty nor null Red @Test public void shouldReturnFalseIfEmailIsNull() { String email = null; EmailValidator validator = new EmailValidator(); boolean isValid = validator.isValid(email); assertThat(isValid, equalTo(false)); }
    13. 13. Neither empty nor null Green public boolean isValid(String email) { return false; }
    14. 14. Neither empty nor null Red @Test public void shouldReturnTrueIfEmailLengthIsGreaterThanZero() { String email = "some@email.com"; EmailValidator validator = new EmailValidator(); boolean isValid = validator.isValid(email); assertThat(isValid, equalTo(true)); }
    15. 15. Neither empty nor null Green public boolean isValid(String email) { if (email == null) { return false; } return email.length() > 0; }
    16. 16. Contains an @ symbol Red @Test public void shouldReturnFalseIfEmailDoesntContainAtSymbol () { String email = "someemail.com"; EmailValidator validator = new EmailValidator(); boolean isValid = validator.isValid(email); assertThat(isValid, equalTo(false)); }
    17. 17. Neither empty nor null Green public boolean isValid(String email) { if (email == null) { return false; } if (!email.contains("@")) { return false; } return email.length() > 0; }
    18. 18. Refactor private EmailValidator validator; @Before public void setUp () { validator = new EmailValidator(); }
    19. 19. In the end…  Components will behave exactly as we want.  Tests will be the documentation of our system.  Tests will break if changes compromise the system.
    20. 20. Thank you! Carlos Andrés Oquendo coquendo@thoughtworks.com @andres19_05

    ×