Written Report on Model (Testing)

Model Analysis and Testing

Model Analysis

Ubiquitousness of Split

After walking through several transaction scenarios that involves splits, one has to appreciate the usefulness and necessity of a split structure for day-to-day transactions.

Though the current application gives the impression that it's incidental, actually in real life it might happen more frequent than we assume. Considering supermarket shopping experiences, a significant proportion, if not most, of our purchase activities belong to split transactions. It's very often we buy things which belong to different categories: groceries, garments, office supplies (educational or small business for tax purpose), medicine for health (tax, flex-spending), etc. It's less often but still not uncommon that we get cash back from the same transaction, or we foot the bill with two or more payment methods (credit cards, bank cards, cash, etc.).

Assume spit is a generic form of transaction, we might as well consider the "normal" transaction, single-source-single-category, a special case - a transaction comprises of only one From source and one To destination. I wonder if this idea would have an impact on the model design, or if the current model is built upon this.

But definitely we can incorporate this idea into the UI design. Which I might as well discuss it in the Report for View (Testing) section.

Testing

Testing Strategy

• Conformance — Does the value conform to an expected format?
• Ordering — Is the set of values ordered or unordered as appropriate?
• Range — Is the value within reasonable minimum and maximum values?
• Reference — Does the code reference anything external that isn't under direct control of the code itself?
• Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
• Cardinality — Are there exactly enough values?
• Time (absolute and relative) — Is everything happening in order? At the right time? In time?

Pre-existing Tests for Split Model

	public void testCompare() throws Exception {
		//Splitting To - all attributes are the same
		//Splitting From - All attributes are the same
	}

	public void testWithoutSplits() throws Exception {}

	public void testWithFromSplits() throws Exception {}

	public void testWithToSplits() throws Exception {}

	public void testWithBothSplits() throws Exception {}

	public void testUnbalancedSplits() throws Exception {}

	public void testWithIncorrectIncomeBCSplits() throws Exception {}

• There are a few method calls in SplitsTest seemed to be redundant. They were in the format of "t.setFrom(new SplitImpl());" or "t.setTo(new SplitImpl());". The later calls, "t.setFromSplits(fromSplits);" or "t.setToSplits(toSplits);", seem to always overwrite their effects.

• In the model, one can add a transaction with all "from" and "to" sources, amounts undefined. Because of the this, one can actually adds 0 split to a split source in a transaction as long as the transaction amount is 0L. Is it what author intended?

Added Tests

1. public void testSplitsZeroToSplit() throws Exception {}
2. public void testSplitsZeroFromSplit() throws Exception {}
3. public void testSplitsToSplitZeroAmount() throws Exception {}
4. public void testSplitsFromSplitZeroAmount() throws Exception {}
5. public void testSplitToSplitsNullSource() throws Exception {}
6. public void testSplitFromSplitsNullSource() throws Exception {}
7. public void void testSplitsToSplitBCincome() throws Exception {}
8. public void void testSplitsFromSplitBCincome() throws Exception {}