Unit Testing - Revision history

Sichen at 18:22, 6 November 2009

2009-11-06T18:22:25Z

Sichen: /* Writing Unit Tests from Bean Shell */

2009-04-02T19:08:06Z

‎Writing Unit Tests from Bean Shell

Sichen: /* Writing Unit Tests from Bean Shell */

2009-04-02T17:22:48Z

‎Writing Unit Tests from Bean Shell

Sichen: /* Writing Unit Tests from Bean Shell */

2009-04-02T17:21:50Z

‎Writing Unit Tests from Bean Shell

Sichen: /* Running a Unit Test from Beanshell */

2009-04-01T19:12:34Z

‎Running a Unit Test from Beanshell

Sichen: /* Unit Tests and MySQL */

2009-03-26T21:01:39Z

‎Unit Tests and MySQL

Sichen: /* opentaps 1.0 */

2009-03-26T21:00:32Z

‎opentaps 1.0

Sichen: /* Warning about running Unit Tests in MySQL */

2009-03-26T20:20:08Z

‎Warning about running Unit Tests in MySQL

Spark at 10:14, 19 March 2009

2009-03-19T10:14:50Z

Sichen: /* Warning about running Unit Tests in MySQL */

2009-03-19T00:16:23Z

‎Warning about running Unit Tests in MySQL

← Older revision		Revision as of 18:22, 6 November 2009
Line 298:		Line 298:

	When runnig a long time test in MYSQL that might cause lock wait timeout error, so we need change the MYSQL innodb_lock_wait_timeout parameter to avoid this issue. See [[Database_Tips#Mysql_Tips\|mysql tips]].		When runnig a long time test in MYSQL that might cause lock wait timeout error, so we need change the MYSQL innodb_lock_wait_timeout parameter to avoid this issue. See [[Database_Tips#Mysql_Tips\|mysql tips]].
		+
		+	==Running and Monitoring Unit Tests==
		+
		+	The opentaps unit tests will take a while to run. To monitor them, pipe the output to a file:
		+	$ ant run_tests > tests.log
		+
		+	Then, you can use <tt>grep</tt> to look for tests that have started and ended:
		+	$ grep 'JUNIT (start)' tests.log
		+	$ grep 'JUNIT (end)' tests.log
		+
		+	and count how many have been run:
		+	$ grep 'JUNIT (end)' tests.log \| wc -l
		+
		+	When they're all done you can look for the results in <tt>runtime/logs/test-results/</tt>
		+	$ ls runtime/logs/test-results/

← Older revision		Revision as of 19:08, 2 April 2009
Line 218:		Line 218:

	Note that print() will put the results back on bean shell console, while the Debug.log methods will put it on the log file.		Note that print() will put the results back on bean shell console, while the Debug.log methods will put it on the log file.
		+
		+	When you get your tests to work, you can put it into the Java test case as a new test method:
		+	<pre>
		+	public void testSupplierInvoicePaymentCycle() throws GeneralException {
		+	// creates suppliers and organization
		+	String supplierPartyId1 = createPartyFromTemplate("DemoSupplier", "Test supplier 1 for accounting tags invoice and payments test " + UtilDateTime.nowTimestamp());
		+	String supplierPartyId2 = createPartyFromTemplate("DemoSupplier", "Test supplier 2 for accounting tags invoice and payments test " + UtilDateTime.nowTimestamp());
		+	String organizationPartyId = createOrganizationFromTemplate("Company", "Test organization for accounting tags invoice and payments test " + UtilDateTime.nowTimestamp());
		+	// ... more testing code
		+	</pre>
		+
		+	Converting the bean shell code to Java is fairly simple. Just copy and paste your bean shell code between the setUp() and tearDown() into the body of your Java method, and then make the following changes which are usually suggested by IDEs:
		+	* type and typecast all your variables
		+	* make sure that doubles are expressed as <tt>1.0</tt> instead of <tt>1</tt>
		+	* fix references to <tt>t</tt>. Since beanshell is not inside a particular class, we had to refer to our test as <tt>t</tt> and access its methods through <tt>t</tt>. Once we put the test code inside of the Java method of a test class, we can access the methods of the Java test class directly, so:
		+	t.createPartyFromTemplate(//...
		+	becomes just
		+	createPartyFromTemplate(//...
		+	and
		+	new FinancialAsserts(t, organizationPartyId, demofinadmin);
		+	becomes
		+	new FinancialAsserts(this, organizationPartyId, demofinadmin);
		+
		+
		+	And that's pretty much it!

	==Debugging Unit Tests with IntelliJ==		==Debugging Unit Tests with IntelliJ==

@@ Line 157: / Line 157: @@
 </pre>
-=== Writing Unit Tests from Bean Shell ===
+== Writing Unit Tests from Bean Shell ==
 You can speed up the process of writing unit tests by developing them in beanshell first, and then putting them into a Java unit test method when you're done.  This saves you the time of repeatedly recompiling and restarting opentaps while you are developing the unit tests.

← Older revision		Revision as of 17:21, 2 April 2009
Line 197:		Line 197:

	Save this test script, and then follow the instructions above to run it from bean shell.		Save this test script, and then follow the instructions above to run it from bean shell.
		+
		+	While writing your unit tests from beanshell, you can "shorten" it to run just a part of it by using tearDown() and return. For example, here I decided to just has one method first inside of a pretty long test:
		+	<pre>
		+	t.setUp();
		+	Map invoiceItemTypeGlAccounts = t.getGetInvoiceItemTypesGlAccounts("Company", UtilMisc.toList("PINV_FPROD_ITEM", "PITM_SHIP_CHARGES", "PINV_SUPLPRD_ITEM", "PINV_SPROD_ITEM"));
		+	print(invoiceItemTypeGlAccounts);
		+	t.tearDown();
		+	return;
		+	//... More testing code which won't be run
		+	</pre>
		+
		+	You can also "cheat" and give yourself the values that you should be testing for:
		+	<pre>
		+	Debug.logFatal("****** finalBalances_CONSUMER *****", "");
		+	t.printMapDifferences(initialBalances_CONSUMER, finalBalances_CONSUMER);
		+	Debug.logFatal("****** finalBalances_GOV *****", "");
		+	t.printMapDifferences(initialBalances_GOV, finalBalances_GOV);
		+	//...
		+	</pre>
		+
		+	Note that print() will put the results back on bean shell console, while the Debug.log methods will put it on the log file.

	==Debugging Unit Tests with IntelliJ==		==Debugging Unit Tests with IntelliJ==

@@ Line 156: / Line 156: @@
 bsh % source("tests.bsh");
 </pre>
 ==Debugging Unit Tests with IntelliJ==

← Older revision		Revision as of 21:01, 26 March 2009
Line 210:		Line 210:
	pause("product average calculation");		pause("product average calculation");

−	When runnig a long time test in MYSQL that might cause lock wait timeout error, so we need change the MYSQL innodb_lock_wait_timeout parameter to avoid this issue. See [[Database_Tips#Mysql_Tips]]	+	When runnig a long time test in MYSQL that might cause lock wait timeout error, so we need change the MYSQL innodb_lock_wait_timeout parameter to avoid this issue. See [[Database_Tips#Mysql_Tips\|mysql tips]].

@@ Line 9: / Line 9: @@
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="http://www.ofbiz.org/dtds/test-suite.xsd">
-     <test-case case-name="security-tests"><junit-test-suite class-name="com.opensourcestrategies.crmsfa.test.SecurityTests"/></test-case>
+     <test-case case-name="security-tests">
 </test-suite>
 </pre>
@@ Line 20: / Line 22: @@
     $ ant run-tests
 your tests will be run.
 ===opentaps 0.9===
 In opentaps 0.9, you would write your Junit tests class and add your it to the base/config/test-containers.xml file, in the "junit-container" at the bottom, like this:

@@ Line 202: / Line 202: @@
 From this point, any data that relies on the partyId is sure to be specific to that test only.  An example would be when we're checking the customer balance against <tt>customerPartyId</tt>.  If we were checking the balance of <tt>DemoCustomer</tt>, then we might be thrown off if another thread happens to create an invoice for <tt>DemoCustomer</tt> at the same time.
-==Warning about running Unit Tests in MySQL==
+==Unit Tests and MySQL==
 MySQL does not store timestamps with a greater than 1 second precision.  Therefore, it could lead to some primary key violations when several attempts to store data with a timestamp as part of the primary key take place within the same second.  For example, if you update the status of an invoice several times during the same second in a test, the InvoiceStatus could experience primary key violations because one of its primary key fields is a timestamp.  To work around this problem, put pauses inside of your test:

← Older revision		Revision as of 10:14, 19 March 2009
Line 208:		Line 208:
	MySQL does not store timestamps with a greater than 1 second precision. Therefore, it could lead to some primary key violations when several attempts to store data with a timestamp as part of the primary key take place within the same second. For example, if you update the status of an invoice several times during the same second in a test, the InvoiceStatus could experience primary key violations because one of its primary key fields is a timestamp. To work around this problem, put pauses inside of your test:		MySQL does not store timestamps with a greater than 1 second precision. Therefore, it could lead to some primary key violations when several attempts to store data with a timestamp as part of the primary key take place within the same second. For example, if you update the status of an invoice several times during the same second in a test, the InvoiceStatus could experience primary key violations because one of its primary key fields is a timestamp. To work around this problem, put pauses inside of your test:
	pause("product average calculation");		pause("product average calculation");
		+
		+	When runnig a long time test in MYSQL that might cause lock wait timeout error, so we need change the MYSQL innodb_lock_wait_timeout parameter to avoid this issue. See [[Database_Tips#Mysql_Tips]]

← Older revision		Revision as of 00:16, 19 March 2009
Line 205:		Line 205:

	When running unit tests in MySQL that use transactions please be aware that an assert failure can issue a rollback on the transaction leaving the data on the database in an inconsistent state, potentially allowing the test to pass even if in reality it failed.		When running unit tests in MySQL that use transactions please be aware that an assert failure can issue a rollback on the transaction leaving the data on the database in an inconsistent state, potentially allowing the test to pass even if in reality it failed.
		+
		+	MySQL does not store timestamps with a greater than 1 second precision. Therefore, it could lead to some primary key violations when several attempts to store data with a timestamp as part of the primary key take place within the same second. For example, if you update the status of an invoice several times during the same second in a test, the InvoiceStatus could experience primary key violations because one of its primary key fields is a timestamp. To work around this problem, put pauses inside of your test:
		+	pause("product average calculation");