Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Outside-In TDD

Transcript from Outside-In TDD

Part 1

  • write acceptance test first (name it ...Feature in a package feature)
    • identify side effects - what are we testing (e.g. text printed to console)
    • identify the trigger of the side effect (e.g. print statement on account)
  • drive implementation from test
  • use UnsupportedOperationException for all methods... that are not yet implemented, to see where things are failing
    • change template of creating a new method in the IDE to create a throw statement in the body of the method
  • acceptance testing means:
    • run trigger for side effect
    • assure expected side effect has happened
  • as acceptance test is failing for the right reason, it's time to "park" the acceptance test and go to the inner loop --> unit testing
  • META split IDE editor: test left, implementation right
  • Outside-In TDD is doing design while writing the tests
  • use void command methods (no return value)
  • do not store things in objects that you can calculate on the fly
    • only if calculation takes too much time
  • META create a shortcut test in the IDE that generates a test method stub (template)
  • start your tests with <CLAAS>Should
  • do not use / implement methods just for the purpose of testing
  • when mocking a class / classes, use @RunWith(MockitoJUnitRunner.class)
  • in acceptance test use real repository, in unit test mock it
    • in unit test, mock external world
  • with introducing a repository, a logic is pushed further down into the system (from Account into TransactionRepository)

Part 2

  • Question to ask when doing outside-in TDD:
    • is the responsibility of class under test to do all of that
    • or is it the responsibility of someone else
  • keep all the methods of a class on the same level of abstraction
  • every time a collaborator of the class under test in the acceptance test is created, a method body of this collaborator will throw a UnsupportedOperationException
    • this way we will be guided on what needs to be implemented next...
    • therefore the Acc tests runs the real class, not the mocks
    • as part of the outside-in process, this means that we start with the class under test and are then guided to the missing points of implementation in the collaborator classes
  • each collaborator then gets a unit test as the next step
    • within the unit test, we can think of what the collaborator class should do
    • collaborators of the class under test in the unit tests are mocked
  • how to mock things like a date
    • e.g. the transaction is saved in the database with a given date, which normally will be created "in time"
    • rule: you can't test what you can't controll (e.g. System.date())
    • you need to controll this randomness in your tests
    • so you need the System.date() to come from something that you can control / mock, e.g. a Clock class
  • META* check Idea shortcut for "recent runs" --> select recent runs of unit tests
  • when you need to test some functionality that you can't control (e.g. a clock / date / time), put the call to this functionality into a protected method and override the class / this method in your test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.