https://github.com/codecop/bankocr-outside-in-kata

Solve BankOCR using Outside-in TDD.
https://github.com/codecop/bankocr-outside-in-kata

code-kata exercise kata mocking outside-in-tdd tdd test-doubles test-driven

Last synced: about 4 hours ago
JSON representation

Solve BankOCR using Outside-in TDD.

• Host: GitHub
• URL: https://github.com/codecop/bankocr-outside-in-kata
• Owner: codecop
• License: other
• Created: 2019-10-06T11:12:48.000Z (about 5 years ago)
• Default Branch: master
• Last Pushed: 2021-04-18T21:05:23.000Z (over 3 years ago)
• Last Synced: 2023-03-12T06:53:25.879Z (over 1 year ago)
• Topics: code-kata, exercise, kata, mocking, outside-in-tdd, tdd, test-doubles, test-driven
• Language: Scheme
• Homepage:
• Size: 128 KB
• Stars: 2
• Watchers: 2
• Forks: 4
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: license.txt

Awesome Lists containing this project

README

        
# BankOCR Outside-in TDD Kata Setup

[BankOCR Code Kata](http://codingdojo.org/kata/BankOCR/), initial setup

for various programming languages focusing on Outside-In development.

## Assignment: BankOCR

You work for a bank, which has a machine to assist in reading letters.

The machine scans the paper documents, and produces a file with a

number of entries which each look like this:

    ····_··_·····_··_··_··_··_·

    ··|·_|·_||_||_·|_···||_||_|

    ··||_··_|··|·_||_|··||_|·_|

    ···························

Each entry is 4 lines long, each line has 27 characters. The first 3

lines contain an account number written using pipes and underscores,

and the fourth line is blank. Each account number should have 9 digits,

all of which should be in the range 1-9.

Write a program that can take this file and parse it into actual account numbers.

**Don't Focus on Getting it Done. Focus on Doing It Perfectly.**

## Constraint: Outside-In

In Outside-In (London school, top-down or "mockist TDD") you build the

system from the "outside-in", following the user interaction through

all the parts of the system. You start with the interactions and collaborators

upfront (especially those at top levels), mocking necessary dependencies (or creating

fake implementations). With every finished component, you move to the previously

mocked collaborators and start with TDD again there, creating

actual implementations (which, even though used, were not needed before

thanks to abstractions). See [Emily Bache's article on Outside-In development](http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/)

for a discussion of Outside-In both with London school and classic TDD.

### License

[New BSD License](http://opensource.org/licenses/bsd-license.php), see `license.txt` in repository.