The TestRunner action is excluded from strategies set using the command line
parameter strategy_regexp. What are the reasons for not being able to map strategies
for the TestRunner?
In the code there is a comment on not overriding test strategies for
backwards compatibility. Do you know what test strategies it may conflict with?
Code that excludes the TestRunner:
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/exec/SpawnStrategyRegistry.java#L93
The background is that I would like to map individual C++ unit tests to remote execution but cannot find any support for that in Bazel? Is there perhaps some other mechanism that can be used for this?
Kind regards,
Jonas Hansson
Related
As part of our efforts to create a bazel-maven transition interop tool (that creates maven sized jars from more granular sized bazel jars),
we want the aspect that runs on bazel build to access the target's java_common.provider in order to fetch the jars and ijars from it.
Is that possible?
The short answer is yes, that's possible.
You can use the java_common module in an aspect implementation the same way you would use it in a rule implementation.
From the documentation on java_common.provider:
java_common.provider.compile_jars and java_common.provider.transitive_compile_time_jars refer to the ijars used at compilation time
java_common.provider.transitive_runtime_jars refer to the full jars used at runtime.
The full jars at compilation time are not yet available, but someone is working on exposing this feature. (Issue #3528 on GitHub.)
Make sure you also read the blog post on this topic: https://blog.bazel.build/2017/03/07/java-sandwich.html
I'm thinking it might be easiest if I modify the Java syntax used in Rascal to better fit our Java-like language.
Is there a way I can build Rascal from the source? I've cloned the repo from Github and imported it as a project into Eclipse but there are some compilation errors regarding org.eclipse.imp. Before I head down the rabbit-hole of trying to get this all to work in Eclipse I thought I would post here to see if there is an easy way to handle this.
Thanks!
Sure you could build Rascal from scratch; following the developer instructions at https://github.com/cwi-swat/rascal/wiki/Rascal-Developers-Setup---Step-by-Step
On the other hand, if you wish to simply adapt the Java syntax definition it would be better to clone it into your own files. Grammars may look modular, but in reality there are complex interactions between different parts of the grammar. Better to clone and manage the whole thing as your own than depend on two co-evolving definitions.
If you clone the Java grammar Rascal will generate new parsers for you on-the-fly. If this generation becomes cumbersome, a "cached parser" can help you to optimize the deployment of your tools. Please contact us if you need help with that.
I am facing the following problems while trying to use the Spock framework
Forced to inherit from Specification , is there any way to use annotations instead ?
Cannot execute individual tests , only option I found from internet is #IgnoreRest annotation, is there any other way to do it ?
ad 1. There is no way around inheriting directly or indirectly from Specification (for good reason).
ad 2. It depends on whether the environment that you are executing tests in (IDE, build tool) allows to execute individual (JUnit) tests.
I've got an Erlang project comprising a bunch of different applications. I'm using Common Test to do some of the testing.
apps/foo/suites/foo_SUITE.erl
apps/bar/suites/bar_SUITE.erl
I'm starting to see duplication of utility code in those suites.
Where should I put my utility code so that it can be shared between the two suites?
I've considered adding another application:
apps/test_stuff
...but I can't make the CT suites depend on this without making the application under test depend on this (or can I?). I don't want to do that, because test_stuff is only needed when testing.
I have a similar problem with my eunit tests, both between applications (apps/foo/test vs. apps/bar/test), and where I'm using similar functionality between the eunit and CT tests in the same application (apps/bar/suites vs apps/bar/test). Can I use the same solution for this case as well? Or do I need to ask another question about that?
Do you think ct:require/1,2 could help you so that foo and bar SUITE would require test_stuff before it gets executed? For more information http://www.erlang.org/doc/man/ct.html#require-1
It depends on how you are packaging your final releases. For example, I use rebar for relase management. I have Cowboy fetched along with other dependencies for testing purposes, but in my reltool.config, I omit it, so it doesn't get packaged with the final product. I use rebar to run Common Test, and it's able to add Cowboy to the path without having it bundled as a lib with everything else or added as a dependency to the app I'm testing.
However, if you have another process which infers your release configuration from your dependencies, you'll have to find a way to exclude your test code when you generate a release.
I am using Specflow with Xunit and what I want is to have the (under the covers) generated unit tests have an Xunit.TraitAttribute added to them. Is that possible with Gherkin and SpecFlow?
Could you clarify what will guide how you would decide which ones should have the attributes? Unless it's a blanket rule, you'll want something that gives you more control than having the same attribute uniformly added to every generated test. Assuming there are T4 templates involved, you could obviously do something in there - bit the bottom line is that angle of attack is going to be messy.
You could so it as a post compile step with Mono.Cecil handily enough. Obviously PostSharp could do stuff like that too, but it might be overkill.