It exist many levels of software testing. They vary depending on the role of the programmer that is going to write the test and the part of the program to be tested. Axional ERP is susceptible of executing Unit, Integration, Performance and Stress tests as it will be seen bellow.

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In the Axional ERP application context, refers to the business logic code stored in dictionary modules:

• Database architecture: Tables, indexes, constraints, etc.
• Database programs: Triggers, procedures and functions.
• Axional Studio Scripts: XSQL-Scripts and server-side Javascripts.

Unit tests can be executed in serveral ways, but it is recommened to use the Axional Test module to perform this type of test. It implements the necessary forms and reports to implement and monitorize Unit tests within the context of an Axional Studio application.

Integration testing verifies the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be located more quickly and fixed. Integration testing works to expose defects in the interfaces and interaction between integrated components. In Axional ERP application the mentioned components, which can be verified by integration tests, are:

• Axional Studio forms interface (User interface business logic)
  • JRepObject configuration: events, expressions, javascript code.
  • Column attributes.
  • Column options.
  • Soft References.
  • Reset logic.
• Axional Studio transaction handler (Server-side business logic)
  • JRepObject configuration: TRX Manager.
  • Database transactions.
  • Validation script.

The same way it happens with Unit tests, it exists many ways of executing Integration tests using external applications. But using Axional Test module implements what is called Black-box testing. It treats the software as a "black box", examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it.

Performance testing is a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.

Stress testing is normally used to understand the upper limits of capacity within the system. It consists of overloading existing resources in an attempt to break the system down. This kind of test is done to determine the system's robustness in terms of extreme load and helps application administrators to determine if the system will perform sufficiently if the current load goes well above the expected maximum.

The test plan is considered the infrastructure to develop the system test. This plan includes both the architecture of the databases and the protocol to carry the test plan out.

The following sections try to explain how to test the different Axional Applications.

ERP Dictionaries provide the functionalities corresponding to each ERP module. It consists on the databases wic_icon for finances, wic_iges for supplies and purchases, etc. The mentioned functionalities are the subject of the test; so, any Test Master Data and Test Data databases should have associated at least one ERP Dictionary.

The JUnit dictionary (wic_junit) is an special dictionary required by Test Master Data databases for enabling the menu options for defining the test cases.

Test Master Data databases has two purposes:

• Test data storage. The ERP Dictionaries provide the necessary structure and forms for adding specific module master data and implementing functional circuits to be tested. Test Master Data is usually a clone of the ERP Master Data database. Thus, it contains the initial data for testing.
• Test cases storage. The JUnit Dictionary provides the necessary structure and forms for implementing Test Case and Test Data.

Finally, Test Data databases are the ones used for tests execution. These databases are the only ones within the Test Environment which might contain volatile information. That is, they can be destroyed and rebuilt, generally as a copy of Test Master Data databases, in order to have consistent data at the beginning of the test execution.

Example

The graphic below shows an example of definition for the following modules:

• RF (wic_term)
• Finances (wic_icon)
• Supplies and purchases (wic_iges)
• Axional Studio (wic_studio)

Notice that Supplies and purchase Module has dependences on two dictionaries (wic_iges and wic_icon).

The following steps defines a good practices guide to executing a satisfactory test plan over an Axional Application:

1. DROP and create the Test Data database (test_[module])
2. Import data from Master Test Data database (junit_[module]) to Test Data database (test_[module])
3. Execute individual test

TDD Test-driven development is an evolutionary agile design technique where you write your test code before your functional code. This way one thinks through the requirements before writing the functional code. The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This approach tests every single line of code, unlike traditional testing.

Test-driven development is related to the test-first programming concepts of extreme programming (XP), as it attemps to reduce development cycles by having multiple shoter ones. Also recommended for rapidly evolving designs.

Write your test code in very small steps: one step and a small bit of corresponding functional code at a time, usually a Unit test. First, a test is written and it is verified that the tests fail. Next, the code that makes the test pass successfully is implemented and then the written code is refactorized.

1. Add a test.
2. Run all tests and see if any new test fails
3. Write some code.
4. Run tests.
5. Refactor code.
6. Repeat.

1. Acceptance TDD (ATTD): write a single acceptance test (behavioral specification) and then just enough production functionality/code to fulfill that test.
2. Developer TDD: write single developer test (unit test) and then just enough production code to fulfill that test.