Please enable JavaScript.

Coggle requires JavaScript to display documents.

The Art of Unit Testing, rate each component for these factors 1(low) -…

- - - - A noticeable end result can be observed without looking at the internal state of the system and only through its public APIs and behavior
        
        The invoked method returns a value
        
        A noticeable change to the state or behavior of the system before and after invocation that can be determined without interrogating private state
        
        There is a callout to a 3rd party system over which the test has no control
- - - - The problem here is that your test cannot control what that dependency returns to your code under test or how it behaves
        
        Solution: Use stubs
      - Definitions
        
        External dependency is an object in your system that your code under test interacts with and over which you have no control.
        
        A stub is a controllable replacement for an existing dependency in the system. By using a stub, you can test your code without dealing with the dependency directly.
        
        Seams are places in your code where we can plug in different functionality. Seams are what we get by implementing the Open-Closed Principle. Examples:
        
        Adding a constructor parameter
        
        Adding a public settable property
        
        Make a method virtual, so it can be overridden
        
        Externalize a delegate as a parameter or property so that it can be set from outside a class.
        
        A mock object is a fake object in your system that decides whether the unit test gas passed or failed. It does so by verifying whether the object under test called the fake object as expected. There is usually no more than one mock per test.
        
        A fake is a generic term that can be used to describe either a stub or a mock object (handwritten or otherwise), because they both look like the real object. Whether a fake is a stub or a mock depends on how it’s used in the current test. If it’s used to check an interaction (asserted against), it’s a mock object. Otherwise, it’s a stub.
        
        Overspecification is the act of specifying too many things that should happen that your test shouldn’t care about
        
        An isolation framework is a set of programmable APIs that makes creating fake objects much simpler, faster, and shorter than hand-coding them.
      - :star: You can't test something?
        
        Add a layer that wraps up the calls to that something and then mimic that layer to your tests or
        
        make that something replaceable (so that it is itself a layer of indirection).
      - How to test easily
        
        :one: Find the interface or API that the object under test works against.
        
        :two: If the interface is directly connected to your unit of work under test, make the code testable by adding a level of indirection hiding the interface.
        
        :three: Replace the underlying implementation of that interactive interface with something that we have control over, a stub.
        
        :check: You can refactor by introducing a new seam into it without changing the original functionality of the code
        
        :warning: make sure that the resulting code does exactly the same thing it did before
        
        Abstracting concrete objects into interfaces or delegates
        
        Refactoring to allow injection of fake implementation of those delegates or interfaces
        
        Inject stub implementation into a class under test
        
        Inject a fake at the constructor level
        
        Inject a fake as a property get or set
        
        Inject a fake just before a method call
  - - - :!: The alternative is the state-based integration test
- - - - Factory methods for objects
      - System initialization methods
      - Object configuration methods
      - Methods that setup or read from external resources such as databases
      - Special assert utility methods
- - - - A unit test should contain a series of method calls with assert but not control flows not even try-catch
      - Most probably test more than one thing
    - - Production bug
      - Remove or refactor test
      - Test bug
      - Semantic or API changes
      - Eliminate duplicate tests
    - - :one: Comment out the production code
      - :two: Run all tests
      - :three: If nothing failed a test should
        be added
      - :four: Write a failing test
      - :five: Uncomment the production code
        and run again all the tests.
        All should pass
  - - - :red_cross: Constrained tests order
      - :red_cross: Hidden test calls
      - :red_cross: Share state corruption
      - :red_cross: Tests should not know the results of other tests
    - - private methods provide a hidden functionality and may change in the future which leads to breaking test
      - :point_right::skin-tone-2: if a private method is worth testing it might worth to make it public or static
    - - :red_cross: assert purely the internal state
      - :red_cross: multiple mocks or stubs
      - :red_cross: assume specific order or exact string matches when it isn't required
  - - - :one: name of the method under test
      - :two: the scenario
      - :three: the expected behavior
    - - avoid writing your own custom assert message