BMunit - Loading many rules for all the test

[rmichoud]

I am trying to come up with a way to load many rules for all the tests.

So far, the only way I saw to do this is to manually add the @BMScripts with a list of scripts for each test class. I can also envision how to augment the code automatically to add this list for each test class. I am looking for a more elegant solution.

Any idea ?

Roger

[adinn]

Hi Roger,

So far, the only way I saw to do this is to manually add the @BMScripts with a list of scripts for each test class. I can also envision how to augment the code automatically to add this list for each test class. I am looking for a more elegant solution.

Any idea ?

I like the idea of being able to specify a set of rules for use across all tests and test classes. Unfortunately, at present there is no very simple way of doing this. It is possible to do what you want but only at the expense of adding stuff to the java command line for the test run. I'll explain that in a second but first let me ask do you have any suggestions as to how you might want to be able to communicate the relevant configuration to BMUnit? I can (and probably will :-) suggest some things but I'd like to hear what you have in mind (if anything).

One way to do what you are asking for is to install the Byteman agent from the command line pre-configured to load the scripts you want at the point where the test JVM is started. In order to make this work you also have to tell BMUnit not to try to load the agent. That latter step is needed because a second load attempt will fail causing BMUnit to abort.

So, if, for example, you are using maven then you need to configure the surefire or fallsafe plugin to install the Byteman agent on the command line. Let's assume (for now) you have just one script in a subdir of test resources scripts/myGlobalScript.btm and that you have byteman-3.10.0 as a dependency. You can configure the following pom properties to identify the jar and the script (n.b it gets copied to ${project.build.testOutputDirectory} by the plugin.

...
<properties>
  <byteman-version>3.10.0</byteman-version>
  <byteman-dir>${settings.localRepository}/org/jboss/byteman/byteman/${byteman-version}</byteman-dir>
  <byteman-jar>${byteman-dir}/byteman-${byteman-version).jar</byteman-jar>
  <byteman-global-script>${project.build.testOutputDirectory}/scripts/myGlobalScript.btm</byteman-global-script>
</properties>
...

You need to tweak your failsafe/surefire configuration to include the agent. Note also the property setting used to stop BMUnit trying to load the agent. Note also that you have to specify listener:true in order to be able to load any extra scripts attached to the classes or tests using BMRule or BMScript annotations.

...
<configuraton>
  ...
  <argLine>-javaagent:${byteman-jar}=script:${byteman-global-script},listener:true -Dorg.jboss.byteman.contrib.bmunit.agent.inhibit</argline>
</configuraton>
...

Obviously if you want to load several scripts you can add multiple script:xxx arguments to the javaagent options list (note the comma separator).

One downside of doing the load from the command line is that some of the settings in any BMUnitConfig annotations attached to your test classes may be ignored. For example, a debug=true setting in the BMUnitConfig for a given test class will no longer enable debug trace for tests in that class. If you want BMUnitConfig annotations still to work then you need to set an extra property on the command line which tells the agent that properties like debug, verbose etc may be subject to update:

<argLine>-javaagent:... -Dorg.jboss.byteman.allow.config.update</argLine>

n.b. BMUnit automatically sets that property at the point where it loads the agent. If yu try to set it after the agent is loaded on the command line it is too late for it to take effect.

I cannot give any guarantees that the above settings are not full of typos (yeah, programmers, mistakes ... :-) but this method does work. Get back to me here if you run into any problems and I will help to debug them. If nothing else that will help anyone else wanting to follow this route.

regards,

Andrew Dinn