New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It's not possible to keep metadata when running FlexUnit tests #77
Comments
I just want to describe this issue more detailed. Suppose you have SWC library project which declares some additional custom metadata tags (for example, Copyable and Cloneable) by using "-keep-as3-metadata+=Cloneable,Copyable" compiler option.
If you try to test your project's code which uses this metadata tags through unit-tests and "gradle test" task you will be fail because "-keep-as3-metadata+=Cloneable,Copyable" option will not be passed to the compiler when it compiles project's source classes in test scope. |
I might be wrong, but did we not discuss the possibility of adding compiler options specifically for the test task?
and so on for any option you might want to override for testing? Or perhaps something like:
I'm just thinking out loud. |
Yes, that's how it will look like on the outside. But in GradleFx we'll have to rework the Test task since it's delegating the compilation to the FlexUnit ant task, which has no parameter to specify compiler options. So instead of delegating the compilation to the ant task, we should do it ourselfs and then just provide the swf to the ant task. |
Let's hope the ant task takes a compiled swf as an argument. Or did you already verify that? |
Yes, you can provide your own swf to the ant task. |
Maybe it would be better to implement the following behaviour in the Test task. By default compiler in test scope will inherit options from additionalCompilerOptions but we keep a way to fully override it with additionalTestCompilerOptions. This is only a suggestion. The other way is dividing of configuration on two (or three) scopes — production and test (and, maybe, development) — by using closures:
I prefer a second way as more evident and less error-prone. |
I like the notion of scopes. I also think both approaches could be combined: example:
|
Hmm, I like your suggestion, Maxime. |
Here's another related issue on StackOverflow: http://stackoverflow.com/questions/14628726/how-do-i-load-rsl-libraries-during-unit-tests-with-flexunit-using-gradlefx Dependencies defined as RSL in the main app are not used in the unit-test application. |
While the configuration style looks pretty, I'm not entirely sure it makes sense. Configurations are used to group dependencies, not for configuration usages (see http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.Configuration.html). Imo it's also just a more verbose way to what we have now (the default config and the test{} subconfig) without adding any benefits. Unless I'm missing something :) |
Well the idea was to add as many configurations as you want; not just the default and 'test'. As an example use case: I need to make a build with mock data embedded to be able to give a demonstration to a customer without a server (or even let him play with it a little while). This other build requires additional source folders, as well as additional dependencies and a different output name, when compared to the default production build. I've been able to work my way around this, but it is a workaround. In the meantime - i.e. after I wrote that previous comment - I've been digging around a little. So I agree with you that what I proposed in that comment, is in conflict with how Gradle works. As you mentioned, the existing Configuration class has a different purpose. The reason is this: using the Java plugin, every Configuration is tied to a different output. So as a conclusion, I'm afraid that it is impossible to bring this feature to GradleFx in the same way as it exists in the Java plugin. Not without completely changing the way things work anyway :( So what are the options:
Waw, I made this sound a lot more dramatic than I meant to, so let me throw in a ;) to lighten things up. |
Come to think of it, now that I wrote that "facets of a configuration" thing down. Would it not be possible to do something like this?
|
So using configurations (merged, rsl,..) inside configurations (compile, testCompile). I'll do some research to see if this is possible. |
On a side note, I just wrote a blog post addressing the multiple configurations issue: |
What are your guys' current thoughts on the best way to get the compiler options to the test task? We've run up against this and were potentially going to try to help with some dev effort (if that's the need), but not sure what the current thinking is. |
It would require a rewrite of the current test task implementation, which at this moment uses the FlexUnit ant task for compiling the test swf. Because we use the ant task to compile the test swf we can't provide additional compiler options, so instead we'll have to compile the test swf ourselves, and then provide that swf to the FlexUnit ant task (using the swf parameter of the ant task). The compilation of this test swf would be done similar to all other compilations in GradleFx, so by using a CommandLineInstruction (see org.gradlefx.cli package). |
For those still stuck with this problem, the guys at GraniteDS worked around this by putting their test code in a separate project so they can use custom compiler options and they also use the FlexUnit ant task directly. Their build script can be found here: https://github.com/graniteds/graniteds/blob/master/build.gradle Take a look at the part where they configure the granite-client-flex45-tests project (currently at line 1483). |
The FlexUnit integration has been completely reworked. This will go into the 0.8 release. |
Currently the Test task doesn't support keeping the metadata, which makes it impossible to run tests.
The text was updated successfully, but these errors were encountered: