In this chapter, we will cover testing of both functionality and performance, as well as the tools used to debug code, in the following topics:
- Unit testing
- Using the debugger
- Automated unit testing
- Creating automated unit test cases
- Creating unit tests with data isolation
- How to run a test case
- Reviewing the results of the unit test
- Code and database performance testing through code profiling
In the last few chapters, we wrote some impressive code, and now it is necessary to make sure it functions as defined by the requirement. The term unit testing means we are testing whether the code fulfils the requirement only, and not how it fits into the whole process.
As part of the unit test process, the focus of the testing is as follows:
- Does the code fit the requirement?
- Is the user interface usable and does it follow AX conventions?
- Is the code efficient in terms of processing and database calls?
If any bugs are found, and subsequently fixed, during the course of testing, it will mean that all tests must be done again, as one fix could break something else, and dry-reading the code for this kind of regression testing is not sufficient.
Even though it is tempting to simply declare the work as done and ready for user acceptance testing, the apparent time saved can be very costly, not just financially, but also in terms of goodwill of the users helping out with the testing process. The end-user acceptance team is busy enough with additional workload on top of their normal tasks, so releasing unfinished code erodes the excitement they may have for the new software.
It may seem the easiest thing in the world to criticize someone else's work, which may seem negative until we consider that we want to deliver good-quality code that performs well and is easy to maintain.
Just because the code works, and even matches the requirement, does not mean that it is ready for release. Ensuring that the code is maintainable and performs well is partly accomplished using standard patterns, but this cannot replace the benefits of a code review by a trained peer.
When planning the process for this book, we had a decision of whether to follow the more traditional bottom-up method, where we write code for a requirement or specification and then perform unit testing, or to use test-driven development (TDD).
We felt that following TDD would detract from this book's core aim of getting started with AX development, but this doesn't mean we won't recommend it. With TDD, we actually write the test case first and then write the code, which of course won't compile until the code is complete. This changes our way of thinking about the code we write, often resulting in better code and a different focus when writing the actual code.
Testing best practices for Microsoft Dynamics AX development can be found at http://www.microsoft.com/download/en/details.aspx?id=27565.