Test Driven Development for MAExtensions

Hi,

I had some spare time so I had a bit of a look into writing some kind of a test template that I could use to test MAExtension code without having to open FIM. The basic idea is to have an xml file with the inputs that would usually be provided by FIM and then expected outputs. Then feed the xml to the extension code methods and compare the state of the dummy connector space or metaverse to some more xml after the extension code has been applied. Automated testing. 

I didn't get very far though because the constructor for MVEntry has no parameters and is protected. This means that I can't create a mock (or fake or dummied) version of a metaverse entry. Without being able to make fake versions of everything I don't know how to do automated testing.

Has anyone tried something similar?  

April 1st, 2011 12:08am

Hi Dan :) ... your predecessors on the same site you're on now have tried to do this before, using NUnit I think, and had some success, but not without a heap of overhead as I understand.  The best way of testing rules extensions code is really only with ILM/FIM Sync Service ... even with all the dummy connectors under the sun!  The best tip I have for you is to use the sync PREVIEW function to test sync on an individual CS object ... you can do full or delta this way, and save yourself a heap of time running syncs on the entire CS.  As for automating tests you can use Event Broker to transition your system between 2 known states, then parse the audit trail (run profile history, log files, etc.) produced to ensure the results are identical between runs.
Free Windows Admin Tool Kit Click here and download it now
April 1st, 2011 2:39am

I'm a big fan of Drop Files for this purpose.  Run Profiles in the sync engine can be configured to use audit files on import/export.

While I don't consider what I do proper Test Driven Development, I like to have test data in the form of drop files.  Ideally I have enough input data (again, in the form of drop files) to get good coverage on the functional requirements, as well as the code and config.  I've even gone as far as gathering/generating the test files ahead of any code/config changes.

The sync engine is still required to run the rules, so you can't do fine-grained unit tests unless you organize your code to separate the IMV and IMA interface implementations from the actual code that does the work.  But if using the sync-engine approach you can get a good deal of automated testing done by using PowerShell and WMI to put the files in place then run the run profiles.

If you're coming to TEC in Vegas then come to my FIM PowerShell session, I'll talk about this during that session, or if you buy me a beer ;-)

April 1st, 2011 6:03am

I'm also an advocate, but haven't used them on anything other than export.  I've been using them to

  • extract pending exports and transforming the XML for reporting (e.g. Excel)
  • extract the applied exports and importing them into a W7 audit reporting system (IBM's TCIM)

I am curious what you mean when you say "test data in the form of drop files" ... do you mean you can replay a drop file?  I've written an ECMA to support this idea by simply reloading the previously created AVP/LDIF file, but I've not tried working with a drop file like that ... can you elaborate a little, or have I misread you?

And if I get to TEC I'd love to buy you a beer ... but I'm not sure I could bring myself to drink what you guys call beer :) 

Free Windows Admin Tool Kit Click here and download it now
April 1st, 2011 6:22am

Drop files work on export (Create a drop file), but they also work on import (Resume from a file).

On import this allows you to 'pretend' you connected to the connected system.  Since I'm usually testing sync rules and not import/export functionality this falacy is acceptable.

So if I have 10 test cases, I'll have at least 10 XML files saved somewhere that I use as import drop files for those test cases.  It usually ends up being more because there's normally sections of code or config that warrant additional testing so I can quickly answer: did my latest code/config change break that really freaky rule that somebody designed?

Oh yeah - I'm pretty sure you won't find real beer on the casino floor, but there is certainly real beer to be found.  I'm after the earned ones, so I'm busting my ass on a mountain bike before the conference (hopefully that's all that gets br

April 1st, 2011 6:31am

Directly a Mock object for CSEntry and MVEntry objects can't be created as they are abstract classes. To create the mock, derived classes for these abstract classes can be created, abstract methods be implemented and then the CSEntry and MVEntry objects can be mocked to load test data (test inputs) from xml file. Also, existing data from FIM database can be loaded directly for MVEntry object for testing. For CSEntry an additional effort would be needed to parse the hologram field.

I have created derived classes for the following and wrote simple implementation for them and I could mock the CSEntry and MVEntry objects.

1.MVEntry

2. CSEntry

3. Attrib

4. ValueCollection

5. Value

This approach would help in unit testing just the Rules Extension and not the complete integration testing. I can share the implementation details if needed.

Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2014 6:22pm

I'd certainly be interested. Do you have a blog post describing this? perhaps you could write an article for the FIM wiki?

Steve G

March 6th, 2015 5:27am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics