Obix has an integrated framework for testing software components. The basic idea is to embed test scripts everywhere in the source code, so that source code can repeatedly be tested in an easy way. The goal of these tests is to quickly find a maximum number of coding errors (bugs) in an early stage of the project.

Obix supports the bottom-up approach for testing software. Small software units are first created and then tested immediately. After checking these lowest level units, higher level units that use lower level units (and/or units at the same level) are created and again tested immediately. This cycle continues until the highest level of abstraction is reached, which is typically the application object.

	Note
	Testing in Obix has a number of commonalities with unit testing which exists as optional third-party additions in other languages (e.g. JUnit for Java).

The rules for writing tests in Obix are explained in the next section.

It is a proven fact that one of the most important and efficient methods for finding coding errors is testing the code by running it under a representative number of normal and exceptional conditions. The better the tests, the more likely are the chances to find remaining errors.

Smart compilers and intelligent code analyzing tools are able to detect some errors, but they can't eliminate the need for testing software before delivery. Hence, testing and debugging software is undoubtedly one of the most important tasks during software development.

However, if testing is not supported by the programming language itself, then testing can be cumbersome and risks resulting in just a few and sometimes sloppy executed manual tests. Most importantly, because of the lack for easily saving and automatically re-executing test cases, there is a high risk of not detecting new errors introduced after changing or extending existing code.

Therefore, support for testing has been integrated in the core of the Obix programming language. It should always be easy for the programmer to write tests, preferably without the need for choosing and installing an optional third-party testing framework.

Moreover, test scripts obviously have a very pleasant side effect. They provide technical documentation about software components in a precise, up-to-date and reliable manner. This reduces (or even eliminates) time spent with the boring task of writing technical documentation as well as the much more boring and error-prone task of updating and maintaining that documentation. Test scripts help to quickly understand the exact behavior of software components. Moreover, because boundary conditions and error generating situations are included in well written test cases, every programmer is well informed about exceptional situations to consider.

For a first simple example of testing a service command, see Example 19.3, “A simple test script example”

To see how a factory can be tested, suppose a tiny application that manages bank accounts.

A bank customer is defined as follows:

type bank_customer default_factory:yes
  
   attribute identifier type:positive32 end
   attribute name type:string end
   attribute city type:string end
  
end type

A bank account is associated with one bank customer. There are two operations: pay_in and withdraw. The source code for type bank_account looks like this:

type bank_account

   attribute customer type:bank_customer end 

   attribute balance type:zero_positive32 default:0 kind:variable setable:factory end 

   command pay_in
      in amount type:positive32 end
   end command 

   command withdraw
      in amount type:positive32 end
   end command 

end type

Suppose the factory to be tested is the following one:

factory bank_account type:bank_account

   command pay_in
      script
         a_balance = a_balance + i_amount
      end script
   end command 

   command withdraw
      script
         a_balance = a_balance - i_amount
      end script
   end command 

   creator create
      in customer type:bank_customer end

      out result type:bank_account end

      script
         o_result.a_customer = i_customer
         o_result.a_balance = 0
      end script
   end creator 

end factory

There are 4 different test scripts that can be written for this factory:

Tests for command pay_in can be written like this:

...

   command pay_in

      script
         a_balance = a_balance + i_amount
      end script

      test
         script
            // create an object for testing purposes
            v_test_object_ = create ( fa_bank_customer.create ( &
               identifier = 10 &
               name = "Foo" &
               city = "Bar" ) )

            // first test case. pay in 100 and verify new balance is 100
            test 100
            verify v_test_object_.balance =v 100

            // second test case. pay in 200 and verify new balance is now 300
            test 200
            verify v_test_object_.balance =v 300

            // fourth test case. pay in too much and produce an arithmetic overflow error
            test se_positive32.max_value
            verify error
         end script
      end test

   end command 

...

A we can see:

Tests for command withdraw can be written in a similar manner.

To test the features of factory bank_account altogether, the following RSE test script can be inserted at the end of the factory's source code, just before the end factory instruction:

factory bank_account type:bank_account

...

   test
      script
         // create a customer
         var bank_customer bc = fa_bank_customer.create ( &
            identifier = 10 &
            name = "Foo" &
            city = "Bar" )

         // create an account
         var bank_account account = create ( bc )

         // check customer attribute of account
         verify account.customer =r bc
         verify account.customer.name =v "Foo"

         // balance must be 0 after creation
         verify account.balance =v 0

         // add 100 to the account
         account.pay_in ( 100 )
         // verify balance
         verify account.balance =v 100
   
         // withdraw 70
         account.withdraw ( 70 )
         // verify balance
         verify account.balance =v 30

         // withdraw 10
         account.withdraw ( 10 )
         // verify balance
         verify account.balance =v 20

         // ...
      end script
   end test

end factory

To execute all test scripts in fa_bank_account, simple execute the run_tests system file (run_tests.sh on Linux or run_tests.bat on Windows) located in the project's root directory.

Alternatively, you can also programmatically execute all test scripts in fa_bank_account with the following code:

         var test_context test_context = fa_test_context.create // create a test context object

         v_test_context.start                        // start the test context (to initialize resources, etc.)
         fa_bank_account.co_test_ ( v_test_context ) // execute all test scripts in fa_bank_account
         v_test_context.stop                         // stop the test context (to release resources, etc.)

For other examples, see also: