Written Report on Model (Testing) - Revision history

Kanke: /* Pre-existing Tests */

2009-10-27T00:40:04Z

Pre-existing Tests

← Older revision		Revision as of 00:40, 27 October 2009
Line 27:		Line 27:
	*Time (absolute and relative) — Is everything happening in order? At the right time? In time?		*Time (absolute and relative) — Is everything happening in order? At the right time? In time?

	=== Pre-existing Tests ===		=== Pre-existing Tests for Split Model ===
	<pre>		<pre>
	public void testCompare() throws Exception {		public void testCompare() throws Exception {

Kanke: /* Pre-existing Tests */

2009-10-27T00:39:22Z

Pre-existing Tests

← Older revision		Revision as of 00:39, 27 October 2009
Line 48:		Line 48:
	</pre>		</pre>

	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.		* 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?		* 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 ===		=== Added Tests ===

Kanke: /* Rules for choosing From and To sources */

2009-10-27T00:37:49Z

Rules for choosing From and To sources

← Older revision		Revision as of 00:37, 27 October 2009
Line 15:		Line 15:


	~~=== Rules for choosing From and To sources ===~~
	*Implied Rules?
	*Filtered list with rules
	== Testing ==		== Testing ==
	=== Testing Strategy ===		=== Testing Strategy ===

Kanke: /* Model Limitations */

2009-10-27T00:37:29Z

Model Limitations

← Older revision		Revision as of 00:37, 27 October 2009
Line 13:		Line 13:
	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.		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.

	~~=== Model Limitations ===~~
	* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

	* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

	=== Rules for choosing From and To sources ===		=== Rules for choosing From and To sources ===

Kanke: /* Planned Tests */

2009-10-26T13:56:51Z

Planned Tests

← Older revision		Revision as of 13:56, 26 October 2009
Line 56:		Line 56:
	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?		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?

	=== ~~Planned~~ Tests ===		=== Added Tests ===


Line 67:		Line 67:
	#public void void testSplitsToSplitBCincome() throws Exception {}		#public void void testSplitsToSplitBCincome() throws Exception {}
	#public void void testSplitsFromSplitBCincome() throws Exception {}		#public void void testSplitsFromSplitBCincome() throws Exception {}
	~~#public void test~~
	~~#public void test~~

Kanke: /* Pre-existing Tests */

2009-10-25T19:41:41Z

Pre-existing Tests

← Older revision		Revision as of 19:41, 25 October 2009
Line 53:		Line 53:

	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.		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?

	=== Planned Tests ===		=== Planned Tests ===

Kanke: /* Pre-existing Tests */

2009-10-25T19:09:33Z

Pre-existing Tests

← Older revision		Revision as of 19:09, 25 October 2009
Line 51:		Line 51:

	</pre>		</pre>

			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.

	=== Planned Tests ===		=== Planned Tests ===

Kanke: /* Planned Tests */

2009-10-25T00:14:21Z

Planned Tests

← Older revision		Revision as of 00:14, 25 October 2009
Line 57:		Line 57:
	#public void testSplitsZeroToSplit() throws Exception {}		#public void testSplitsZeroToSplit() throws Exception {}
	#public void testSplitsZeroFromSplit() throws Exception {}		#public void testSplitsZeroFromSplit() throws Exception {}
			#public void testSplitsToSplitZeroAmount() throws Exception {}
	#public void testSplitsFromSplitZeroAmount() throws Exception {}		#public void testSplitsFromSplitZeroAmount() throws Exception {}
			#public void testSplitToSplitsNullSource() throws Exception {}
	#public void testSplitFromSplitsNullSource() throws Exception {}		#public void testSplitFromSplitsNullSource() throws Exception {}
	#public void ~~testSplitsToSplitZeroAmount~~() throws Exception {}		#public void void testSplitsToSplitBCincome() throws Exception {}
	#public void ~~testSplitToSplitsNullSource~~() throws Exception {}		#public void void testSplitsFromSplitBCincome() throws Exception {}
	~~#public void test~~
	~~#public void test~~
	#public void test		#public void test
	#public void test		#public void test

Kanke: /* Planned Tests */

2009-10-24T23:53:36Z

Planned Tests

← Older revision		Revision as of 23:53, 24 October 2009
Line 55:		Line 55:


	#public void ~~testZeroSplitSplits~~() throws Exception {}		#public void testSplitsZeroToSplit() throws Exception {}
	#public void ~~testZeroAmountSplit~~() throws Exception {}		#public void testSplitsZeroFromSplit() throws Exception {}
	#public void ~~testNullSourceSplit~~() throws Exception {}		#public void testSplitsFromSplitZeroAmount() throws Exception {}
	#public void ~~testNullAmountSplit~~() throws Exception {}		#public void testSplitFromSplitsNullSource() throws Exception {}
	#public void ~~testOutOfContextSourceSplit~~() throws Exception {}		#public void testSplitsToSplitZeroAmount() throws Exception {}
	#public void ~~test~~		#public void testSplitToSplitsNullSource() throws Exception {}
	#public void test		#public void test
	#public void test		#public void test
	#public void test		#public void test
	#public void test		#public void test

Kanke: /* Model Limitations */

2009-10-22T22:07:00Z

Model Limitations

← Older revision		Revision as of 22:07, 22 October 2009
Line 14:		Line 14:

	=== Model Limitations ===		=== Model Limitations ===
	* One split per transaction - either from or to can be a split but can not be both split within the same transaction.		* One split per transaction - either from or to can be a split but can not be both split within the same transaction. (may not be due to model, but rather buggy implementation.)

			* The model allows duplicated data or computed data in two places - split and transaction. This incur duplicate implementations which is potentially error prone.

	=== Rules for choosing From and To sources ===		=== Rules for choosing From and To sources ===