Unlearn Unit Testing

According to wiki, unit tests are automated tests created and executed by software engineers to make sure a part of an application conforms to design specifications and functions as intended. Even though writing looks very simple, there are many issues that come up in practice. Usually, when we try to maximize code coverage, all we end up with are time-consuming, fragile, useless test files. We keep refactoring unit tests without actually gaining anything for the codebase. What if I said that one of the most poorly understood things we perform as developers is unit testing? I'll explain what unit testing actually entails, how it affects TDD, and how to create non-brittle unit tests in this session.

Transcript

1. UNLEARN
   UNIT
   TESTING
   WHY MOST UNIT TESTING IS WASTE
   lemi orhan ergin
   co-founder, craftgate
   STOP WHAT YOU ARE DOING
   CHANGE YOUR MIND !
   

   View Slide

2. This talk is mainly for
   

   the ones who write tests
   

   but feel something wrong
   

   with the written tests, and
   the way we do testing
   

   View Slide

3. The biggest threat for software is being rot
   in time due to unmanaged dependencies
   almost all principles and design patterns aim to
   
   
   decrease coupling and increase cohesion
   

   View Slide

4. Source code is the real software design.
   Designing software is an exercise in
   managing complexity.
   What is Software Design? The C++ Journal Vol. 2, No. 2. 1992
   http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
   Reference:
   Jack W. Reeves
   Author of the "(B)leading Edge"
   column for the publication C++ Report “
   

   View Slide

5. The software design is not complete
   until it has been coded and tested.
   Testing is part of the process of
   

   refining the design.
   What is Software Design? The C++ Journal Vol. 2, No. 2. 1992
   http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
   Reference:
   Jack W. Reeves
   Author of the "(B)leading Edge"
   column for the publication C++ Report
   “
   

   View Slide

6. If someone says "this code is hard to
   test", it means "your design simply
   sucks"
   His Talk at Devoxx Poland
   https://www.youtube.com/watch?v=pnRAnP8MgBc
   Reference:
   Venkat Subramaniam
   Programmer, Author, Speaker,
   Founder Agile Developer
   “
   

   View Slide

7. functional acceptance testing
   
   
   regression testing
   
   
   prototypes, wireframes
   
   
   simulations
   exploratory testing
   
   
   a/b testing
   
   
   usage analytics
   
   
   user acceptance testing
   
   
   alpha / beta
   unit testing & tdd
   
   
   integration testing
   
   
   api compatibility via contract testing
   testing non-functional properties
   
   
   performance testing
   
   
   load testing
   
   
   security/penetration testing
   
   
   static code analysis
   
   
   checking quality attributes
   BUSINESS FACING
   TECHNOLOGY/IMPLEMENTATION FACING
   concept de
   fi
   ned by
   
   
   Brian Marick
   
   
   and revised by
   

   Lisa Crispin &
   

   Janet Gregory
   SUPPORT
   THE
   TEAM
   pass/fail
   con
   fi
   rmation
   
   
   checking for
   expected
   outputs
   
   
   preventing
   defects
   CRITIQUE
   
   
   THE
   
   
   PRODUCT
   driven by data
   analysis and
   investigation
   
   
   analyzing
   unde
   fi
   ned,
   unknown and
   unexpected
   
   
   fi
   nding defects
   TESTING QUADRANTS
   manual
   manual&
   AUTOMATED
   AUTomated
   DID WE BUILD THE RIGHT THING?
   DID WE BUILD IT RIGHT?
   HOW CAN I BREAK THE SYSTEM?
   CAN THE SYSTEM SCALE?
   AUTOMATED
   
   
   via special
   tools
   before/while coding post coding
   

   View Slide

8. unit testing and integration testing
   

   View Slide

9. unit testing and integration testing
   are totally misunderstood concepts
   concepts are so simple that no one even
   
   
   think about it, but feel it in their hearts
   

   View Slide

10. There are two types of unit tests
    
    
    cement unit tests: it makes the
    source code as hard as concrete and
    impossible to be refactored
    
    
    behavioral unit tests: the other one
    enabling TDD and validating
    behaviors easily
    

    View Slide

11. unit tests are automated tests for
    testing individual elements of code fast
    in an isolated and highly targeted way
    

    View Slide

12. unit tests are automated tests for
    testing individual elements of code fast
    in an isolated and highly targeted way
    Misconception Alert: Accepted by the majority, but misleading
    

    View Slide

13. Due to the misunderstanding of unit tests
    

    we face with the inevitable
    we focus on implementation details of the code
    
    
    we massively use mocking for isolating the units, i.e. methods
    
    
    we don’t write tests when the production code is not stable
    
    
    we skip tests while building since fixing it requires too much work
    
    
    we write tests after production code to verify if its working or not
    
    
    we believe in the importance of high test coverage
    Misconception Alert: Accepted by the majority, but misleading
    

    View Slide

14. mock returns another mock
    Setup
    Exercise
    verify
    

    View Slide

15. 103 lines in one test
    1 line for calling actual method
    
    
    2 assertions
    
    
    1 line for verification
    
    
    %95 of method is for mock setup
    

    View Slide

16. Due to the misunderstanding of unit tests
    

    we face with the inevitable
    Misconception Alert: Accepted by the majority, but misleading
    unit tests makes the codebase
    as hard as concrete
    

    View Slide

17. Due to the misunderstanding of unit tests
    

    we face with the inevitable
    it is usually too expensive and time consuming that
    
    
    makes no real advantages exist
    Misconception Alert: Accepted by the majority, but misleading
    we say it’s impossible to write unit tests in this legacy code
    

    View Slide

18. integration tests are automated tests for
    testing group of components against
    real external libraries, services and data
    

    View Slide

19. integration tests are automated tests for
    testing group of components against
    real external libraries, services and data
    Misconception Alert: Accepted by the majority, but misleading
    

    View Slide

20. Misconception Alert: Accepted by the majority, but misleading
    Due to the misunderstanding of integration
    tests, we face with the inevitable
    we focus on functionality of the requirement
    
    
    we massively use dependency injection for connecting components
    
    
    we boot up database etc. and that makes it too slow overall
    
    
    we write tests to verify if functionality is working or not
    
    
    we create tests after coding the functionality is completed
    

    View Slide

21. Misconception Alert: Accepted by the majority, but misleading
    Due to the misunderstanding of integration
    tests, we face with the inevitable
    integration tests are enough, no need expensive unit tests
    we say
    

    View Slide

22. View Slide

23. MOST UNIT TESTS ARE
    TOTALLY WASTE
    
    
    REMOVING MORE VALUE
    THAN ADDING
    

    View Slide

24. LET’S UNLEARN WHAT
    YOU’VE LEARNED SO FAR
    
    
    AND FOCUS ON WHAT
    EFFICIENT UNIT TESTING
    REALLY MEANS
    

    View Slide

25. a user story is an explanation
    of a feature written from the
    perspective of the end-user
    needs
    A user can post
    

    resumes
    

    to the web site
    it ideally! includes all conversations, ideas,
    
    
    decisions, meeting notes and the acceptance criteria
    PREREQUSITE INFORMATION
    

    View Slide

26. PREREQUSITE INFORMATION
    user stories focus on what the user needs
    instead of what the system should deliver
    it’s not the brick in the wall (i.e. the software)
    

    View Slide

27. a use case describes the
    step by step process a user
    goes through to complete
    that goal using a software
    system.
    it is the system’s behavior when interacting with a user
    
    
    a user story can be converted into multiple use cases
    
    
    use cases are transformed into algorithms
    PREREQUSITE INFORMATION
    

    View Slide

28. PREREQUSITE INFORMATION
    use case defines the system behaviors and
    it is a brick in the wall (i.e. the software)
    

    View Slide

29. bounded contexts define the shape of the
    software solving specific domain problems,
    regardless of your team’s size and your
    imagination about which microservices you
    should have
    we split the domain into contexts, not microservices
    
    
    transactions happen inside, messages transfer between contexts
    PREREQUSITE INFORMATION
    

    View Slide

30. source code having two actors and multiple
    
    
    features accessing kafka, elastic search, redis,
    
    
    database and an external web service
    

    View Slide

31. bounded context contains business logic
    
    
    no mutations on shared states
    
    
    data with behaviors
    

    View Slide

32. For every implementation, a contract is defined
    
    
    that leads us to create fake implementation
    
    
    for efficient testing
    

    View Slide

33. Separate the domain logic to another build root
    from technology specific integration code to
    distinguish modules
    

    View Slide

34. unit is the behavior, testing a use case
    
    
    no need for a mocking framework
    
    
    all business logic can be tested by unit tests
    

    View Slide

35. unit tests are automated tests for
    testing individual behaviors fast by
    focusing on contracts in isolation
    fake implementations for building the feature
    

    before deciding the technology and as using it
    

    like a test double
    

    View Slide

36. unit tests are automated tests for
    testing individual behaviors fast by
    focusing on contracts in isolation
    where you enter the system
    and start the process EXIT
    EXIT
    EXIT
    ENTRY
    the behavior or the results
    you get at the end,
    

    either returns a value, or
    changes a system state, or
    calls a third party system
    you should write a test for
    each exit point
    Reference: The Art of Unit Testing, 3rd Edition, Roy Osherove
    https://www.artofunittesting.com/
    

    View Slide

37. unit tests are automated tests for
    testing individual behaviors fast by
    focusing on contracts in isolation
    fake it till you make it is the heart
    of TDD, tests can drive design easier
    when you postpone technology
    decisions and integration code
    

    View Slide

38. integration tests are automated tests for
    testing the points where the system under
    test interacts with an external system
    we call implementations of the integration points
    as adapters in ports & adapters terminology
    

    View Slide

39. Two bounded contexts
    
    
    demand report
    
    
    

    generate report
    and
    

    View Slide

40. Key Principles
    Unit tests should validate behaviors
    
    
    Write unit tests validating internals for validating algorithms
    
    
    Business flows should be tested very fast
    
    
    Integration tests should validate interaction points with technologies
    
    
    No need to use a mocking framework at all
    
    
    Mock only shared state
    
    
    Tests interact with contracts, handle like a black box
    
    
    Tests should not change by refactoring the implementation details
    
    
    Functional tests validate the functionality from outside
    
    
    Code coverage means nothing more than a report
    

    View Slide

41. https://github.com/AlicanAkkus/Modular-
    Architecture-Hexagonal-Demo-Project
    ali can akkuş
    software crafter
    craftgate
    lemi orhan ergin
    co-founder
    craftgate
    code samples:
    improved version
    

    with DDD will be
    

    available soon
    

    View Slide

42. Programming Paradigms
    
    
    Code Smells in OOP
    
    
    Stroustrup’s School of OOP
    
    
    Alan Kay’s School of OOP
    
    
    Message Passing in Practice
    
    
    Misconceptions about OO
    SOLID Actually Means
    
    
    Single Responsibility Principle
    
    
    Open Closed Principle
    
    
    Liskov Substitution Principle
    
    
    Interface Segregation Principle
    
    
    Dependency Inversion Principle
    1 2 Test Double and Usages
    
    
    Mocking Anti-Pa
    tt
    erns
    
    
    When Mocking Sucks
    
    
    Writing Mock-Free Code
    
    
    Unit Testing Best Practices
    
    
    Test Doubles and Modularity
    3
    Current state of unit tests
    
    
    Why most unit tests are waste
    
    
    Two types of unit tests
    
    
    Bonded contexts, ports & adapters
    
    
    Testing the behavior
    
    
    Design easier with TDD
    What is so
    ft
    ware quality
    
    
    How quality assurance fits
    
    
    Steps to increase quality
    
    
    Keeping the design testable
    
    
    Customer service impact
    4 5 6
    

    View Slide

43. THANK YOU FOR
    
    
    SHARING YOUR TIME
    
    
    WITH ME
    speakerdeck.com/lemiorhan
    
    
    twitter.com/lemiorhan
    lemi orhan ergin
    co-founder, craftgate
    mail: lemi@craftgate.io
    

    View Slide