« Home | Expense Calculator - Session 3 » | Expense Calculator - Session 2 » | Expense Calculator - Session 1 » | Expense Calculator Started » | Hibernate Mappings & Encapsulated Collections » | My Desk » | Using Agile Practices » | Automated Tests are Great » | Changing Mindset » | Business Knowledge and Software Projects »

Expense Calculator - Session 4

In session 1, we implemented requirements 1 and 2. And sessions 2, 3 we spent time simplifying the design. At this stage we are now good enough to move on to implementing the next requirement.

Requirement 3: Generate an expense sheet for a payer for a list of transactions for a date range.

Steps:
Wriet junit test case. While writing the test case I realize I have not added a date to transactoins. :-). So wear refactoirng hat and add date attribute to transaction.

Next is handling date range. For me I have a Transaction class with date attribute. I guess that eventually the interface will boil down to a list of transactions. My query should fetch me the valid transactions. So i see something like party.getexpesesheet(transactions) as the interface.

I complete test case, it fails. then i implement it and it passes.

I have done the test for a payer. I do it for a receiver. IT also passes (claps) at first attempt.

I am keeping my unit tests very simple. My automated functional tests which will load a real long list of transactions and generate expense sheet will really test this functionally out. But at class levels thses tests suffice. Thats what I think now but this can change later on ;-)

Now I have added one more junit test case. I have 2 test cases. I scan the two and refactor them to form a heirarchy. This session really went smooth and fast. So thats what our rythm should be: write test case, fail, pass, refactor to simplify design, next req, test case, fail pass, refactor and so on.

At the end I just try to review my classes. And I see something. EquitableDistribution and NonEQuitableDistribution. The latter (or both) class names are misleading. Why? I said earlier non equitable = where payer doesnt have a share in expenses. So the prefix non applies to 'payer doesnt'. But read nonequitable and it means not divided equally. Misleading ha. I come up with right names. EquitableWithParty and EquitableWithoutParty. I do the rename refactoring.:-). I also see something coming up: PartlyEquitableWithParty ... ;-) probably. But when it comes I will handle it.

Next I move on to implement requirement 4: Generate an expense sheet for a receiver. This is pretty straight forward.

A rythm has surely developed :-)

The updated class diagram for domain and test sources look like this:

Domain class diagram:

Posted by Hello


Test class diagram:

Posted by Hello

Links to this post

Create a Link