Skip to content

Latest commit

 

History

History
83 lines (41 loc) · 5.15 KB

README.md

File metadata and controls

83 lines (41 loc) · 5.15 KB
Raw

Acceptance Testing a Bank Account

You are part of the development team responsible for building out a new online retail bank offering. In a previous session, you built out basic account functions like depositing and withdrawing funds. Now, the product owner wants to build out the next phase making the offering more appealing to those customers just waiting to sign up.

Prerequisites

You will need Java and an IDE.

  1. Clone the repository with the following command.

    git clone https://github.com/xp-dojo/atdd-bank-account

    If you have problems with SSL, you can try the following.

    git clone -c http.sslVerify=false https://github.com/xp-dojo/atdd-bank-account

    If you have problems with a proxy, you can unset http_proxy and unset https_proxy (or equivalent for your OS).

  2. Open the project from IntelliJ IDEA (community edition is fine).

  3. Make sure you can run the unit tests (make a change and see one or more tests fail).

  4. Make sure you can run the acceptance tests. Hint: run the Index.java just like an ordinary test.

Instructions

This session is all about working with your customers (in this case the product owner) to understand their requirements and writing acceptance tests that you can show them to make sure you've understood them correctly and they're happy with what you're building. Just like the TDD session, you should write your acceptance tests before the implementation and think about small, iterative development cycles.

  1. Read this document fully and then the customer interview transcript.

  2. Brainstorm your list of requirements.

  3. Write your first set of acceptance criteria around the requirements for a statement. Do this in the form of a HTML "specification" in ViewStatement.html. Find inspiration in the ViewBalanceSlip.html example. Run the test and see it fail.

  4. Drop into the TDD cycle (red, green, refactor) to implement the requirement.

  5. Finish by running your acceptance test and see it pass.

  6. Expand your suite of acceptance tests and repeat the cycle above.

Iterative vs incremental development: do you know the difference? Ask an instructor if you're not sure.

Structure

  1. You should start by asking the product owner what she wants you to do. Read the transcript of the interview you conducted last week to remind yourselves of the details, and if there are enough instructors, they will be posing as product owners to field any clarifying questions you may have in person.

  2. Write one or more acceptance tests. Capture what you think the product owner's acceptance criteria are, in business language. Tools like Concordion and Cucumber allow you to write these "specifications" in (more or less) English. Whatever format you choose, you shouldn't be writing code at this stage but specifications.

  3. Write "fixture" or "steps" code to bridge your human readable specification to the code that implements the business logic.

  4. Make your specifications executable. This is where you wire the test fixture code from step 3. to the specifications in step 2. Ask an instructor about syntax if you get hung up.

  5. Most of this business logic code, or API is already implemented for you but you may need to write more.

What do you think is meant by "test fixture"?

In science, a fixture is often physical apparatus used to support a test specimen during an experiment. The experiment or test is distinct from the apparatus that supports it. Unit testing frameworks often muddy this idea because they expect tests to include test support code (the fixture part) as well as the actual test scenarios (the experiment part).

Specifications and Fixtures

The majority of tooling helps abstract the customer authored acceptance criteria or specifications from the test fixture code that proves them. By keeping these two ideas separate, your test code will continue to work as the underlying system grows. Without the separation of concerns, your specifications become brittle and require more maintenance as you refine your understanding.

The Concordion tool describes the idea graphically like this.

You will bridge your specifications (in this case written in HTML but they may be so called "feature" files) to executable code through instrumentation. The specifics vary between tools, but the basic concept is the same. The skill is in keeping the specification abstract and all the implementation detail in the fixture, test and production code.

Hints

The steps above are iterative: you're meant to go through them more than once (and not always in the same order). Try something small and get feedback. Can you think of a way to get feedback and refine using the mechanisms above?

Additional Reading

Concordion documentation
Problems with Acceptance Testing