Test Driven Development for the Tridion Event System – Is it worth it?

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

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.

This entry was posted in Tridion news by Nickoli Roussakov. Bookmark the permalink.

About Nickoli Roussakov

Nick is a SDL Tridion Consultant and takes part in solving a wide range of business challenges in content management primarily through the use of SDL Tridion, .NET and J2EE. Nick manages the North American side of Content Bloom, undertaking a variety of tasks including consultancy, development and developer mentoring.

3 thoughts on “Test Driven Development for the Tridion Event System – Is it worth it?

  1. I’ll have to revise my comment to that answer now, Nick! I suggested we didn’t have much info on Test Driven Development for the Event System. :-)

    Nice write-up and I agree with the post. The development method should match the environment, rather than assuming the approach or even “Event System” before the business and functional requirements.

  2. You should just do step 8 an 9: Let the testcode act as if an event is triggered in tridion, invoking the business code and then assert the results.

    The question is, how to do that? The businesscode subscribes to the eventsystem using something like:
    EventSystem.Subscribe(Handle, EventPhases.Processed);

    So if a component gets published, the Handle method is called. How can the testcode mock publishing a component, so that we can test the Handle method?

  3. To get the answers to your questions a substantial amount of effort and time would be required, not to mention the complexity. I’m up for solving challenges, but only when it is fruitful enough. Which brings us back to my original conclusion that we’re better off just testing manually in this case.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>