Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Unlearn Unit Testing

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.

Lemi Orhan Ergin

December 11, 2022
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Technology

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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  8. unit testing and integration testing

    View full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size slide

  14. mock returns another mock
    Setup
    Exercise
    verify

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

  22. MOST UNIT TESTS ARE
    TOTALLY WASTE


    REMOVING MORE VALUE
    THAN ADDING

    View full-size slide

  23. LET’S UNLEARN WHAT
    YOU’VE LEARNED SO FAR


    AND FOCUS ON WHAT
    EFFICIENT UNIT TESTING
    REALLY MEANS

    View full-size slide

  24. 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 full-size slide

  25. 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 full-size slide

  26. 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 full-size slide

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

    View full-size slide

  28. 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 full-size slide

  29. source code having two actors and multiple


    features accessing kafka, elastic search, redis,


    database and an external web service

    View full-size slide

  30. bounded context contains business logic


    no mutations on shared states


    data with behaviors

    View full-size slide

  31. For every implementation, a contract is defined


    that leads us to create fake implementation


    for efficient testing

    View full-size slide

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

    View full-size slide

  33. unit is the behavior, testing a use case


    no need for a mocking framework


    all business logic can be tested by unit tests

    View full-size slide

  34. 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 full-size slide

  35. 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 full-size slide

  36. 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 full-size slide

  37. 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 full-size slide

  38. Two bounded contexts


    demand report



    generate report
    and

    View full-size slide

  39. 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 full-size slide

  40. 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 full-size slide

  41. 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 full-size slide

  42. THANK YOU FOR


    SHARING YOUR TIME


    WITH ME
    speakerdeck.com/lemiorhan


    twitter.com/lemiorhan
    lemi orhan ergin
    co-founder, craftgate
    mail: [email protected]

    View full-size slide