The Service Station column is a series of articles about providing professional services around EMC software products. Featured guest columnists express their thoughts about a wide range of topics relating to designing, developing, and delivering solutions. In this issue, Jeff Rosler talks about Test Driven Deployment.

Welcome back to the Service Station

Hi All. Welcome back to the service station. Or, perhaps I should say, welcome back to writing something, Jeff. Over the last several months, I, like many people have been focusing on the upcoming release of D6. I’ve been trying to better understand what is in D6, what it will mean to me as a developer and consultant, and what it will mean to my customers.

D6 Product Announcements

Many of you may have attended the Developer Conference last year as well as EMC World in May to hear about product enhancements and changes for D6 as well as the solutions that others have been putting into place and that are available in the market.

The bad thing about any product announcement is the anticipation. You hear news about new features and perhaps see some product demos and then you ask, 'but when can I get this?' Even when the time seems near to when it’ll be available, you then find out that you can’t install it right away because you have to wait until you can convince your IT infrastructure group that they need to install it so you can utilize the new features.

I feel like I’m a kid in a candy store whenever new products and releases come out, or I hear about them. It reminds me of the anticipation of summer movies. You see movies trailers ahead of time and anticipate the release for so long.

In thinking about what to address in this article, I didn’t really want to say anything about D6 since I know that many of you still may not see it for some months. Instead, I thought about what I spoke of in the previous Service Station article that I wrote around solution delivery. What information or guidance could I provide that developers, administrators, and project managers could use today? Forget that anticipation problem. What could I tell people that would allow them to be productive right away?

Test Driven Development – An immediate way forward

My first thought was Test Driven Development (TDD). If you haven’t been doing TDD, or you’ve tried in the past, and dropped it, or didn’t know how to correctly apply it to Documentum, I’d like to explain how you can adopt it.

Put simply, Test Driven Development is the practice of figuring out what you’ll test in your code, writing a test, implementing the code, making the test work, and refactoring the code into a semblance of order. This process of writing unit tests has been called red light, green light, refactor.

• Red light - I wrote the test and it fails – so the GUI shows red
• Green light - I created my business logic so that the test now succeeds when it calls it
• Refactor - I refactor my code to make sure that it’s object oriented and fits my design needs

How does this help me?

How can this help you, you ask? Here are a few of my favorite reasons:

• Aids in better design
  Helps check data encapsulation and reuse by reusing business logic in a test harness. If your business logic is all jammed up in the presentation layer, it makes it harder to maintain and reuse.
• Makes it easier to change project personnel
  If someone else takes over another developer’s code and makes changes, the unit tests serve as an immediate mechanism for indicating that a new change broke something.
• Makes it easier to handle design or requirement changes
  If code is changed to add a new feature, the unit tests act as a check to make sure that the new changes don’t break current functionality.
• Finds problems sooner in the project rather then later
  It allows testing to be done in a harness rather then needing to wait until everything is integrated to be tested. This is not to say that early integration is bad, I’d do that too.
• Aids in Communication
  Developers can tell what they are going to build and address based on what tests they plan. Also, you can get a better idea of task completion if you break your tasks up into smaller units with tests.
• Edge conditions can be regression tested
  It makes you think about what conditions are being tested. If everything is a “happy path”, you can add more edge conditions to your tests and verify that your implementation handles them appropriately.

Applying Test Driven Development with Documentum

One of the biggest complaints that I’ve heard from people that are attempting to apply Test Driven Development to Documentum is that they don’t see how they can create their unit tests in various product scenarios. Here is what I’d do in a few different product customization scenarios.

WDK

If you are making WDK customizations that require backend business logic, you should be able to encapsulate your business logic in classes that can be tested with JUnit tests. It usually isn’t necessary to have the entire WDK framework in place. This doesn’t allow you to test the user interface, but it does allow you to test your business logic.

I wrote some code not too long ago where I was creating a WDK customization that added a new menu item that created an XML Document based on objects in the clipboard. It extended the new document web component, exported a document template, and updated that document based on the objects in the clipboard. It was pretty easy to separate out the business logic from the WDK in order to call this from JUnit as well as the WDK. This allowed me to test my code and get it working in the WDK environment fairly easily.

Automated methods in workflows

If you are creating a method in a workflow, you are usually getting some content from an associated package or object in a package, or looking at values on objects created when the workflow is created (from the dmi_workitem, dm_workflow, etc.). It can be hard to create the workflow as part of a unit test and automatically run it to the activity that contains the method you wan to test, so a developer might say this can’t be easily done.

Most of the time, you can separate out your non-workflow based business logic into classes and methods that can be called from a JUnit based test framework. Don’t focus on testing the whole Documentum method as a single test, but the major components within that Documentum method. If you look closely, you’re probably not passing the workflow related objects to every method and if you are, it’s almost a certainty that you can bubble these up in your internal logic and just pass essentials. I would argue that would be better design and better encapsulation in your code.

Test Driven Development testing in other Documentum scenarios

It is true that implementing tests to do complete integration testing can be very difficult, but finding the tests within your use cases is not always as difficult as it looks at first. Start by asking yourself, what logic can be pulled away from your implementation? Then ask yourself, not how to create integration tests, but how can you create smaller unit tests that will exercise functionality? After answering these questions, you will see tests that can be created.

How do I start?

Hopefully, you’ve listened to my arguments and decided that you’ll go ahead and start implementing TDD. If you are coding in java, the best way to start is to get a framework and test environment in place and start creating tests. For the moment, I’ll assume you are doing your development in Java.

• Install JUnit (http://junit.sourceforge.net/) and read the samples
• Create a small simple test for your code
  1. Define your test
  2. Create Setup logic (e.g. get a Documentum session, and create any needed test objects)
  3. Create Teardown logic (e.g. delete any test objects created in the setup, and release the session)
  4. Call your code (passing your session and other needed params in) – Normally this would be just a place holder to your code
  5. Run the test. You can do this directly from your IDE (e.g. Eclipse, Intellij, etc.), through an ant script, or by using the JUnit GUI client
  6. RED LIGHT - See the test fail, since you haven’t written your business logic yet
  7. Fix your business logic code and run the test again. Keep at this until your test works.
  8. GREEN LIGHT – Your test worked!
  9. REFACTOR – Now that your test works, refactor your code to clean it up (perhaps create other methods or classes)
  10. Re-run your test and make sure that your refactored code is still working
• Create new tests for your functionality and continue on
• Optionally add tests to your build script (e.g. ant) so that when a build is done outside of your IDE, your tests will be automatically run

Want To Know More?

There’s a lot of good information out on the web as well as books about writing unit tests. Google around and you will find a wealth of information and samples. If you’re not using Java, there are also test harnesses available for other languages (i.e. check out NUnit (http://www.nunit.org/) if you are creating .NET tests).

The best advice that I can give you, is just go out and do it. Set yourself a goal and write some tests. Doing it is the best way to learn. Happy, testing!

About the author

Jeff Rosler is a Senior Architect with Flatirons Solutions and has over 22 years of experience in software development and 6 years of experience developing solutions for EMC Documentum products.

About the Service Station

The Service Station column looks at developing EMC based solutions from the perspective of professional services organizations. If you (and your company or department) provide such services and are interested in being a guest columnist, please send your contact information, a brief bio and topic outline to EDN_Submission AT EMC.com.

Click here for an index of all "Service Station" columns.

You can discuss "Service Station" articles on the EDN Forums by clicking here.