Example of test case

For those who ventured too far - just hope they know their way back :)

Moderator: neilg

Example of test case

Postby neilg » Sat Apr 08, 2006 1:29 am

Please note - and this is very important which people tend to skip over when they start this subject - this code was written before any of the main code was written

The purpose of this code was to develop code which converted oracle sql statements to something compatible with hsqldb (a java database).

Code: Select all
package test.com.knowledgesuccess.testing;
import org.hsqldb.CtfOracleSubstituter;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

public class TestCtfOracleSubstituter extends TestCase {
   public TestCtfOracleSubstituter(String arg0) {
   public static Test suite() {
      return new TestSuite(TestCtfOracleSubstituter.class);

   public void testMe() {
      String sql;
      sql = CtfOracleSubstituter.doAllSubstitutions("select * from testTable2 a join " +
            "testTable3 b on a.idColumn = b.idColumn(+)");
      assertEquals("select * from testTable2 a join testTable3 b on a.idColumn = b.idColumn"
            ,sql );//this is incorrect - should be a right join?
      sql = CtfOracleSubstituter.doAllSubstitutions("select case value when " +
      "'X' then '1' else '2' end case from testTable2");
      assertEquals(sql, "select case value when " +
      "'X' then '1' else '2' end from testTable2");
      sql = CtfOracleSubstituter.doAllSubstitutions("select TRIM('x') from testTable2");
      assertEquals("select trim(both from 'x') from testTable2", sql);
      sql = CtfOracleSubstituter.doAllSubstitutions("select * from testTable2 a " +
      " join testTable3 b on a.idColumn = b.idColumn(+)");
      assertEquals("select * from testTable2 a " +
            " join testTable3 b on a.idColumn = b.idColumn", sql);

Let me just appeal to everyone who is a developer. Make this your way of life. :)
Posts: 141
Joined: Thu Jun 16, 2005 1:58 pm

Testing abd compiere

Postby neilg » Sat Apr 08, 2006 1:41 am

However writing tests in compiere is far more tricky. The problem is that the state of the database changes, Tests rely on state to be reset.

Tests also rely on good (M-V-C) style layering of code. Sadly this is lacking in compiere. A gui is quite often mixed in with the business logic. These cases make writing tests very difficult.

Frederick Tsang's solution to the dilemma was to recreate a client (on demand) and populate with fresh data (a big undertaking) for each test run.

My proposed solution in the compiere framework was db independence and copy-over file db with a small foot print (refresh can take a few seconds).

The production code for tests near the end of my involvement with this project (which involved unit testing, thanks to the genius of Fred) was as follows (names changed to protect the innocent):

I hope if vishee or fred see this they will not sue me :) I just wanted to supply a real world example.

Code: Select all

public class TestStockInquiry extends ServiceProviderTestCase
    WebFacadeImpl impl  = new WebFacadeImpl();
    public void testStockInquiry() throws ServiceProviderException

        Properties ctx = dealerAOrg.getCtx();
        int idTr[] = PO.getAllIDs(MZZTransmission.Table_Name, "AD_CLIENT_ID=" + Env.getAD_Client_ID(ctx) + " and VALUE='Auto'");

*      ***************** TEST 1 - View My Stock *********************
        ServiceProviderBean ServiceProviderBean1 = new ServiceProviderBean();
        //Get All Stock from Manager
        ServiceProviderStocksBean stock1 = impl.getAllStocksBean(ctx, ServiceProviderBean1, AssetStatusValues.WholeSale, OwnerStatusValues.MINE, ReservedStatusValues.ALL);

        ArrayList list1 = stock1.getStocks();
        //Compare expected value with the one received from Manager
        assertEquals(0, list1.size());

*      ***************** TEST 2 - Stock Inquiry for MOTHERCOMPANY Only *********************
        //SCENARIO 1
        //Test stock inquiry > ServiceProviderBean (bean here) is not being populated so

I cut the rest of the code off. It is the properietry property of UDI inc and is simply not polite or relevant to post the whole class.

Many of the tests especially in the early stages were written retrospectively. This was done to rescue the project. This is a very desperate state to be in.

You code the test first which helps you drop off the irrelevant stuff which us developers think the customer might need one day.
Posts: 141
Joined: Thu Jun 16, 2005 1:58 pm

Return to Strictly Technical

Who is online

Users browsing this forum: No registered users and 2 guests