Question

I've started to write a class for permission checking on writing and updating objects to a db. For development and testing the permission checking can be disabled via a play config value. My first take was to write the tests with the permission checking enabled. If the check is disabled while the test is run, I simply disable the test via

    org.junit.Assume.assumeTrue(false);

Of course this means that in development, when permission checking is disabled, the tests will be probably never run.

Would it be more proper to have two code paths in each test, one for config enabled, one for config disabled?

Also, is this the time to introduce a mocking framework that inject config values via static method replacement at will? When googling I stumbled over https://blog.codecentric.de/en/2011/11/testing-and-mocking-of-static-methods-in-java/ that recommends PowerMock for the job.

An alternative would be to create a static wrapper class for the play configuration values and allow the change of values there at will.

Which way is preferable?

  1. make the config configurable during runtime
  2. use a mocking framework to change the (static) methods at will
Was it helpful?

Solution

I vote for #1 - make the configuration configurable. I wrote a "framework" (two methods in a superclass) in one of my applications to allow the test to say what it wants the security role to be for the test (and putting it back at the end). This lets the test choose which role it wants to be run under independent of all other conditions.

I've used the same approach for other types of configuration as well.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top