Documentation for testing

[FagnerMartinsBrack]

Hi, I want to unit test my ConfiguratorProviders without inspecting the application behavior. Let's say I create a complex rule with a complex constrainedBy condition, what I want to do is provide a mock for the constrainedBy condition and check whether my rules are working properly. It helps to avoid regression without the need to check the application behavior every time I make a change.

Is there any docs for doing this?

[chkal]

No, there is currently no documentation for something like this.

You could try to use the rule API directly in your tests, but I'm not sure if this will easy to do. You could create a testing RewriteEvent and call the methods manually. It's worth a try.

However, I think integration tests would be a better way to test something like this.

By the way. If you just want to test a Constraint<?>, you can simply refactor the creation of the constraint instance to a method and then use this method to get the configured constraint in your test which then could call the API directly.

[FagnerMartinsBrack]

By the way. If you just want to test a Constraint<?>, you can simply refactor the creation of the constraint instance to a method and then use this method to get the configured constraint in your test which then could call the API directly.

I don't want to test a Constraint<?>, I want to test the rules themselves. As I mentioned "what I want to do is provide a mock for the constrainedBy condition and check whether my rules are working properly".

You could try to use the rule API directly in your tests, but I'm not sure if this will easy to do. You could create a testing RewriteEvent and call the methods manually. It's worth a try.

Well, I have no idea how the internals work, so I am not able to do such thing.

Unit testing is a very useful feature when you want to test your rules inside the app without having to restart the server and test each rule every time.

Integration tests does not work for me, if I am supposed to use Arquillian I should not use in the main project because there are several dependencies and the internal codebase is always changing (too much mocking maintenance). I should instead create a separate project, but the rewrite rules are related to the business and I have EJB calls inside my *Provider class, so I can't split them easily.

Unit testing the *Provider class would be very useful for regression tests and safe manipulation of the rules in the future. At least I would ensure my rules are working as I expected, despite any complex RegEx or rules.

Any thoughts?

[chkal]

Yeah, I agree that unit testing rules may be very useful if you have very complex rules.

If you want to understand how the Rule API is used internally, I suggest to have a look at this method:

rewrite/impl-servlet/src/main/java/org/ocpsoft/rewrite/servlet/impl/DefaultHttpRewriteProvider.java

Line 100 in c960607

private void rewriteInbound(final HttpServletRewrite event)

This method basically does this:

• Load the configuration and retrieve a list of all rules
• Iterate over all rules and do this:
  • Process the rule if Rule.evaluate() returns true (if it evaluates to false, skip the rule)
    • Execute all preoperations
    • Execute the main Rule.perform() method
    • Execute all postoperations

So if you want to unit test your rules, you could do the following:

Just manually create an instance of HttpInboundRewriteImpl providing mocked HttpServletRequest, HttpServletResponse and ServletContext objects via the constructor. Or you could create your own implementation of the HttpInboundServletRewrite interface which HttpInboundRewriteImpl implements. I'm not sure which of the two ways work better and/or is simpler.

Then you could write some code that basically does the same as the method I referenced above:

• Get a list of all rules from your provider
• Iterate over all rules and check if evaluate() returns true. If this is the case, do this:
  • Run preoperations
  • Run perform()
  • Run postoperations

Now you should be able to verify the desired behavior on the mocked servlet objects.