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:
Test class diagram:
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:
Test class diagram:
Comments