Unit test has to keep its unit, even with FileNet
In Unit Test, there is Unit, and people tends to forget that when writing tests with FileNet. That means your test should not rely on anything else than itself, especially not FileNet. Because then what happens? Your tests fail because the platform is down, the test user credentials changed or a network error occurred, and after a while you’ stop noticing the error, thinking “that’s the platform again, but the method’s fine”, or worst, you end up disabling test on your build, because they are becoming a liability more than a help.
Well, this is not how unit test work, I guess you already know that but still. A unit test has to be perfectly reliable, that’s means if your method produce the right outcome, the test should always pass, no matter what, if the test fail, there is something wrong with the method, and you MUST take a look at what’s wrong, not ignore the failure. If you write true unit test, this should be true and you can enable test in the build, and trust failures as real defects.
I’ll write in another post how to set up PowerMock, and some examples so this one does not become to long.
How to make FileNet development not rely on FileNet
Now let’s talk about how to write unit test with FileNet. This is not an easy situation since every method will depend on the FileNet API, and we don’t want that. What we are going to do is we will mock FileNet class. However this is more complicated that classic mocking, because there is no IoC in FileNet, making mock injection impossible, and use of static method as quite the standard in the FileNet API. So what I came up with, is using PowerMock. It changes the bytecode of class at runtime and allows you to mock static method, final class and so on. Of course this is not perfect but this is a pretty good start, and will give you a fantastic head start for testing, even if you still have work to do.
Downside of such a test
There is one downside though, sometimes the test depends highly on the FileNet API, i.e. if there is a small change in the API, the unit test might fail even if it is still working, or at the contrary, the test can still pass because you mocked a specific version behavior, but this is not working with the new version. Well this is what Integration Tests are for!
Another down side is that it is hard to mock FileNet at a high level of abstraction, meaning you can mock and object and just ask him to answer than he has 2 sub-folders and 2 documents, that is not so easy, and that is also what Integration Test are for. That means you have to mock all part, and that makes your test pretty weak in case of change to the method. Because the method could still be correct but the test fail because you did it another way, for example using get_Containees instead and get_ContainedDocuments. Well that’s a downside but not so much, because you should always verify that the test is working with your new method. A unit test is written more to avoid regression that to test new implementation without changing it. Of course in a perfect world also called Test Driven Development, we would write test first and once for all. But sadly sometimes it won’t be possible with FileNet, and you’ll have to adapt your test when changing a method.
This doesn’t really matter. Because the most important thing that we want is that if the test PASS, then the method id CORRECT, if the test fail, there is something WRONG, and that’s all. If you change your implementation, you could have false negative, but at least when the test fail, you know for sure there is something wrong with either the test, or the method, and you need to fix one or both anyway.
