An interesting question has been asked on Tridion Stack Exchange regarding whether there are any frameworks or methodologies for using Test Driven Development with the Tridion Event System. Having done test driven development in my early days as a Java and PLSQL developer and having had developed enough functionality with the Tridion Event Systen, I thought I’d provide my two-cents. Test Driven Development, as most of you know, is an approach to development where the developer writes unit tests for their functions prior to writing the functions themselves. The process begins by writing function stubs, then writing down a list of test cases that the function is expected to pass and executing these unit tests. The latter part can be done by creating another program (e.g. via a framework like JUnit, NUnit, PL/Unit, etc or a custom testbed program) that executes the function and asserts the output, but it can also be done manually. In most cases, developers unit test their code manually. The difference with TDD is that you would compile your list of unit tests prior to actually writing the functional code.

As a developer, a technical lead, and a solutions architect I do not believe in using a framework like JUnit or NUnit.  In my humble opinion, they are a huge waste of time.  You spend hours (and sometimes days) coding up your unit tests, only to have them fail on the next iteration because of some data problem, so you end up writing more unit test code than actual functional code.  You also tend to constantly revise the unit test code – time better spent fixing bugs with the real code and working on clear communication with your team and clients.

So how do we apply TDD for something like the Tridion Event System?  For starters, let’s consider what we have to do to write an event and get it running in the CMS:  

1. Write your event function and subscribe to it.
2. Compile the event DLL
3. Stop the Tridion Service(s) on the CM server
4. Deploy the DLL to the configured folder on the CM server
5. Start the services back up
6. Set up your CM test data (test component, page, etc) – this is often the long tedious part.
7. Trigger the event in the CMS
8. Check/assert the results

So with TDD (the manual way), our list would get ammended as follows:

1. Write your event function stub and subscribe to it.
2. Write a list of unit test cases that the function should pass.
3. Compile the event DLL
4. Stop the Tridion Service(s) on the CM server
5. Deploy the DLL to the configured folder on the CM server
6. Start the services back up
7. Set up your unit test data in the CMS (test component, page, etc)
8. For each unit test case in your list trigger the event in the CMS
9. Check/assert the results
10. Write the actual function and repeat steps 2-9

Now, consider having to automate all these steps for something like NUnit.  You can certainly automate the deployment of the DLL to the CMS and execute your NUnit tests via a batch script.  The main challenge is that there is no easy variable to look at that you can run an Assert function against.

For example: let’s say you have an event that automatically publishes
a page on page save. Your unit test would then need to have code to
trigger a page save event in the CMS (you can do this via the Core
Service), then it needs to examine the publishing queue and run an
Assert function on whether it sees the page with “success” status.
However, you’d also need to account for the time it takes to process
the publishing (e.g. Waiting for deployment, deploying, and finally
success).

My point is, suddenly your development team is writing more unit test
code than actual code for the required functionality.  Using a TDD framework is simply
not worth the effort in the case of the Event System.