My TDD Avatar
=============

This project is an implementation of the app outlined here http://blogs.agilefaqs.com/wp-content/uploads/2007/12/avatars-of-tdd.pdf as used to demonstrate various TDD Avatars. A TDD Avatar is a style or approach to TDD, different styles have different impact on the design of the final application, which is a property I find interesting.

The problem definition
----------------------
Design a Veterinary Information System for a Clinic. Veterinary medical system is very similar to human medical system with one exception, all the patients are animals. Each patient is owned by a person, who brings the patient to the clinic and pays the bills.

The person in charge for IT department of the clinic gave us the following Use Cases to start development. Dave Atkins brings his pet named Fluffy into the clinic for a routine check up and shots. The veterinarian charges him for the routine office visit and the Rabies vaccination. Dave pays cash before he leaves and is provided with a receipt for the services.

Initial Design Sketch
---------------------
Given a problem definition I tend to go into design mode automatically and for the problem above came up with the following initial design.

Appointment     Charge       Invoice         Payment   Receipt
- owner         - treatment  - appointment   - amount  - invoice
- patient       - cost       - payments
- procedures                 - total_due
- invoice

Initial UI Design Sketch
------------------------
I also like to think about the UI as this will have a major impact on the design and highlights what data needs to be captured and displayed.

Appointments Page, list of appointments and form to add a new appointment with owner name and patient name, button next to listed appointment
to show a specific appointment.

Appointment Page, displayed by clicking on Show button from Appointments page. Displays owner name, patient name, list of procedures carried out. Drop down list of procedures and button to add a procedure. Link to Invoice page.

Invoice Page, displayed by clicking Invoice link on Appointment Page. Displays owner name, patient name, list of procedures and costs, list of payments made and total due. Form to add payment, payment amount and Add button.

Receipt, printed version of the Invoice Page.

Updated Design Sketch
---------------------
Receipt is redundant, it's just a printed invoice.

First Story
-----------
Looking at the problem definition I split it into 3 stories

1. Create appointment for walk in owner/patient
2. Add charges
3. Settle invoice with cash and receive receipt

For the first story, looking at the UI sketch, a quick spike shows up the need to create an Appointment class with an owner and patient.

The First Test
--------------
The first test I write is a unit test for creating an appointment. Which I make pass by creating the class and a migration for the fields. I tend to think outside-in and then implement inside-out (or middle-out using Fowler's term)

Controller and View
-------------------
With the model in place I can now add the controller index and create methods. My controller tests use real object instances not mocks, and assert things about the view.

Second Story
------------
Adding charges. First thing is based on the UI sketch I want to show a specific appointment. So write a test for AppointmentsController#show. Next, again checking the UI sketch I need to show a list of procedures carried out and a drop down list of procedures to add. Showing the drop down is going to require a list of charges from somewhere, my current design sketch has a charge object but that is something associated with an appointment, so getting a list of all procedures/charges is going to result in duplicates and potentially different prices. Another class is required. Borrowing from the Domain Neutral Component pattern we can introduce the description archetype and add a ChargeDescription class. So the design sketch of what is required so far is now:

Appointment     Charge          ChargeDescription     
- owner         - description   - treatment
- patient       - cost          - cost
- charges                 


Test wise I now have a short to-do list 
- create a charge from a charge description
- add a charge to an appointment

Back to the controller, update the appointments show test to include charge descriptions. 

Final Story
-----------
Adding payments. Taking a step back it seems that there is no real value in having an invoice class as the majority of its behaviour would be delegated to the appointment, e.g. list of charges, name of patient, etc. Seems like things can be simplified by just adding payments to an appointment. The updated design sketch is now.

Appointment     Charge          ChargeDescription     Payment
- owner         - description   - treatment           - amount
- patient       - cost          - cost
- charges                 
- payments
- total_due

Test list
- Add a payment to an appointment
- Calculate total due on appointment
- appointments_controller#update can add payments