Development Tips

Testing Best Practices

There is always trade-off between Quality & Quantity of deliverables.

Sometimes small Partners don’t want to invest on resources and time for their deliverables to make big profits.

Sometimes customers are not interested in paying more for their customizations requested, their after they keep investing on recursive fixes for their solutions.

Sometime requirement is not well aligned with Business Logic and the process keeps refining over the time.

Which leads to arguments on Product capability and Partner Quality of work.

Whatsoever may be the reason but before any piece of code is moved to the Production environment should be well tested and accepted by the clients/customers.

Microsoft recommends the following best practices for designing your application tests:

  • Test code should be kept separate from the code that is being tested. That way, you can release the tested code to a production environment without releasing the test code.
  • Test code should test that the code being tested works as intended both under successful and failing conditions. These are called positive and negative tests. The positive tests validate that the code being tested works as intended under successful conditions. The negative tests validate that the code being tested work as intended under failing conditions.
    • In positive tests, the test function should validate the results of application calls, such as return values, state changes, or database transactions.
    • In negative tests, the test function should validate that the intended errors occur, error messages are presented, and the data has the expected values.
  • Automated tests should not require user intervention.
  • Tests should leave the system in the same well-known state as when the test started so that you can re-run the test or run other tests in any order and always start from the same state.
  • Test execution and reporting should be fast and able to integrate with the test management system so that the tests can be used as check-in tests or other build verification tests, which typically run on unattended servers.
  • Create test functions that follow the same pattern:
    • Initialize and set up the conditions for the test.
    • Invoke the business logic that you want to test.
    • Validate that the business logic performed as expected.

For more details see below Links:

Creating a Test Codeunit and Test Function
Creating a Test Runner Codeunit
Adding a Test to a Test Runner Codeunit

2 thoughts on “Testing Best Practices”

  1. Hi there,

    good start 🙂 Let me add a small detail: Operating an automated test system requires a certain minimum team size, and experienced test writers. Also, keeping the test code in a separate tree in source control helps. The most important part is experience in ERP design and usage for the test writer(s), IMO. Automated testing can have so many blind spots otherwise that lead to a big pile of unmanageable code and bad UI decisions. One of the pitfalls of automated testing is that no human verifies the actual usability and intuitiveness of a UI change. As you can see everywhere in the software industry, even at Apple… The things that irk humans on a UI don’t pop up in automated testing. The same is true for inadequately detailed workflows, and ambiguous error messages. An automated tester only makes an assert() for a condition, but if the possible error message is apropriate is hard to test (therefore, experienced test writers).

    with best regards



Comments are closed.