Testing and Debugging Custom AgileShape Projects

Custom AgileShapes (including AgileParts and AgileWorks) are not stand-alone applications, and are only intended to be fully executed within the context of an AgilePoint Server instance. Like other "hosted" code (e.g. ASP.NET code-behind code; ASP.NET user and server controls; SharePoint modules; etc.), the behavior of the code at run time depends upon the state of the server. Although this makes unit testing more difficult than for a non-hosted application, it is an unfortunate consequence of the hosted-component model.

Therefore, at this time our official recommendation is to test AgileShapes using actual process models on a real AgilePoint Server installation, because this most closely emulates a production environment. This can be done either manually and/or using custom test applications that use the AgilePoint APIs to start and monitor the test processes.

However, there are certain steps you can take to make unit testing of your code more feasible. The first step is to separate as much of your AgileShape's code as possible into static methods and/or into separate class libraries. This should allow such separated code to be more easily unit testable outside of the hosting environment.

Another alternative is to implement a "fake server" by creating one or more custom classes that implement the AgilePoint interfaces required by your code at run time (e.g. IWFApi or IWFWorkflowService). The complexity of implementing such a solution will depend on how closely you need the "fake server" to mimic a real server. Although this would likely require more time than most developers would wish to spend, this would be the most comprehensive way to make AgilePoint-hosted components fully unit testable.