Quality Assurance

Quality is at the heart of what Arxxus do

Our Quest for Quality

At Arxxus, our consultants drive quality at all stages. We are constantly on the lookout for better ways to do things. We look for solutions of elegance that are Faster, Higher, and Stronger. Our project delivery engines support this drive for quality by providing constantly, and reinforcing feedback from experiences in delivering enterprise software.

Our core delivery methodology rests on being relevant to customer needs, being accurate in problem identification and resolution and finally, in being consistent and regular in customer engagement.


Where possible, we drive Test Driven Development (TDD) at all levels. This approach validates the build at all times, ensuring the correctness of the solution at a fine-grained level.

From a unit testing perspective, TDD relies on the philosophy that tests should be created before code is written:

  • Don’t write production code unless it is to make a test pass
  • Test code should be minimal - but enough to fail any missing production features
  • Don’t write any more production code than what is required to pass the test

If you write a block of code that you think will be difficult to test, STOP AND REFACTOR to reduce that block to smaller testable blocks. The same principle of validation applies to requirements analysis, where User Acceptance Test Cases can be used to validate the requirements.

Our Guidelines for Testable Code

Smaller code blocks, i.e. smaller classes and smaller methods are, as a rule, easier to test than larger ones. Also, following the Single Responsibility Principle while designing code eases testing since the code block then has exactly one reason to change, thereby reduces the number of tests required to ensure its correctness.

Some general guidelines for writing easily testable code:

  • Decouple code as far as possible to allow for independent testing - use Inversion of control or reflection where appropriate.
  • Reduce parameter sets on functions for easier testing - use nonadic/monadic functions rather than larger argument sets.
  • Ensure larger parameter sets are wrapped into container data structures for easier testing.
  • Push decision making UP the value chain - so that downstream code is easier to test.
  • Design for failing early in the code chain (including validation for security restrictions)
  • Reduce global state - making test writing easier.
  • Where complex global state is required, decouple functional blocks into separate classes (utility patterns) that can be independently tested.
  • Separate context building from testing - use builder patterns to construct state before testing.
  • Create common relationship data idioms using datasets or factories for easier testing.
  • Reduce static methods - especially avoid static state or configuration settings where possible - these are difficult to test.


Some of our customers