How do I disable code generation in my test plugin?

1
votes

I have a couple of test files written in my DSL in my tests plugin/project. Most of the tests use inline multi-line strings and Xtend but in four cases, I need to test code which does some magic with URLs and the classpath, so I really need resources in the classpath for that.

Since loading the resources only works when the extension is correct, I can't give the files a fake extension.

Now my problem: My DSL also has a code generator. This means that eventually, I end up with a couple of generated files in places where I can't have them (they don't compile, for example, and one even contains an error to test error handling when information is split across several files).

I can't disable the Xtext nature because the tests project uses Xtend so for these files, I do need code generation.

Since the generator runs inside Eclipse (I have the DSL plugins installed for other projects), there is no way to override the code generator in Guice.

How can I disable the code generator in this case?

1
junitcode-generationxtext
Your setup is very complex, and it's a bit hard to understand what you are really trying to accomplish... Are these "test files written in my DSL" actual JUnit tests, or do they contain data used for testing? Are the tests you are trying to do unit tests or integration tests? Which part of the system are you testing - the code generation part, or stuff that has to be generated first? Why can't you mock the resources, or generate the appropriate test code along with the rest of the files? - weltraumpirat
My test files are data used by tests. I'm not sure whether they are UTs or ITs in this case - does it matter? I'm testing my own code generator, Xtext's CG works. I explained why I can't mock the resources: They must be on the classpath. I'm considering to change the test case to copy the resource to the bin/ folder but I was wondering if that's the best approach. - Aaron Digulla
The difference between UT and IT would be that in a unit test, I would always try to find a way to mock all dependencies, whereas the whole point of integration tests is to see if all the parts fit together... In your case, I'd say unit test first, then see if there are any blind spots left in your test coverage. Where do you get the classpath details from? There has to be a call by which the generator gains access to those, so that's the dependency you should be mocking (i.e. return fake classpath entries, and verify the "magic" against those). - weltraumpirat
That's an interesting idea. How do I mock org.eclipse.xtext.resource.ClassloaderClasspathUriResolver? - Aaron Digulla
Have you tried mockito? code.google.com/p/mockito - weltraumpirat

1 Answers

1
votes

There is a simple way to achieve this:

  1. Open the properties of your project
  2. Expand the entry for your DSL
  3. Select "Compiler"
  4. Select "Enable project specific settings"
  5. Disable/deselect "Compiler is activated" under "General"

If you don't have a properties entry for your DSL:

  1. Add this fragment to your .mwe2 workflow file:

    fragment = generator.GeneratorFragment {}

  2. Regenerate your projects

  3. Merge the new code from plugin.xml_gen into plugin.xml both in the base and the UI plugins.

The interesting parts are the two extension points org.eclipse.ui.preferencePages and org.eclipse.ui.propertyPages