After some modifications for test configuration
test {
scanForTestClasses = false
include '**/*Test.class'
include 'lt/inventi/apollo/scenarios/**'
}
My tests started to fail with error java.lang.Exception: Test class should have exactly one public constructor
so my workaround is like so
test {
scanForTestClasses = false
include '**/*Test.class'
include 'lt/inventi/apollo/scenarios/**'
exclude '**/*$*' //fixed
}
Is this correct way?
Once you turn off test class scanning, it's your responsibility to filter out all non-test classes. If you can't be more specific than scenarios/**, you'll have to compensate with an exclude (like you already do).
Note that it's perfectly fine to use test class scanning together with include/exclude filters.
I had this issue exclusively on a mac, and found 2 issues:
There was a bug #4544 on Gradle versions prior to 4.7, causing inner classes to be picked up
The mac JVM I happen to use (Zulu 1.8, installed via SDKMan) had issues when namespaces were capitalised (and the associated folders were too). This was fine with Zulu 1.8 in ubuntu, but lower-casing the folders seemed to do the trick
Related
I am currently running my cucumber scenarios like this with JUnit 4:
#RunWith(Cucumber::class)
#CucumberOptions(
features = ["src/features"],
tags = "not #ignored"
)
class RunCucumberTest
I am trying to get the same working on JUnit Platform, and currently have:
#Suite
#IncludeEngines("cucumber")
#SelectDirectories("src/features")
#ConfigurationParameter(key = Constants.PLUGIN_PROPERTY_NAME, value = "pretty")
#ConfigurationParameter(key = Constants.GLUE_PROPERTY_NAME, value = "garden.ephemeral.rocket")
class RunCucumberTest
I have updated the stuff on the Gradle side as well:
tasks.withType<Test> {
useJUnitPlatform {
// TODO: Not needed? Doesn't seem to work with or without.
includeEngines("cucumber")
}
jvmArgs("--add-modules=jdk.incubator.vector")
// Workaround. Gradle does not include enough information to disambiguate
// between different examples and scenarios.
// TODO: Move to cucumber.properties?
systemProperty("cucumber.junit-platform.naming-strategy", "long")
// TODO: Move to junit-platform.properties?
systemProperty("junit.jupiter.execution.parallel.enabled", "true")
}
When I run Gradle, the :test task runs, but the test report is empty.
When I try to run the test class from IDEA, I get:
> No tests found for given includes: [garden.ephemeral.rocket.RunCucumberTest](--tests filter)
How do I make this work?
Investigation so far:
I also tried moving the features into the resources and using #SelectClasspathResource("features") instead, but got the same result.
I tried cloning this project and it does run its scenarios, but everything is written in Java instead of Kotlin. Other than that, everything is mostly the same between the two. That project uses #SelectClasspathResource instead of #SelectDirectories, but I already tried that. I also tried using #SelectDirectories over in that project, and that works too.
If I breakpoint inside DiscoverySelectors.selectDirectory, it doesn't seem to stop there. Best guess is, maybe JUnit isn't even finding and running the suite? Or maybe breakpointing inside JUnit just doesn't work.
Best current idea is to convert that skeleton project to Kotlin and see if it still runs.
At a glance this doesn't look right:
useJUnitPlatform {
// TODO: Not needed? Doesn't seem to work with or without.
includeEngines("cucumber")
}
With the #Suite annotation you are using the JUnit Platform Suite engine to kick of the Cucumber engine. By setting the included engines to cucumber you exclude the suite engine from gradles discovery process.
Note that the skeleton project uses:
tasks.withType<Test> {
useJUnitPlatform()
// Work around. Gradle does not include enough information to disambiguate
// between different examples and scenarios.
systemProperty("cucumber.junit-platform.naming-strategy", "long")
}
How to write a test (functional, unit, integration) to test a class that contains a Grails converter(s)? At the minimum I should be able to write a working integration test.
Example: The following line works fine outside of the test scope, but fails in both unit-tests and integration tests:
def json= "{}" as JSON
with GroovyCastException: Cannot cast object '{}' with class 'java.lang.String' to class 'grails.converters.JSON'. The expected outcome is that a JSON type is returned.
There seems to be the same problem with earlier versions in GRAILS-4715, however its been closed so I assume it was fixed. In Grails 3.X this issue could be circumvented like this How do I unit test a Grails service that uses a converter?. However, none of the presented workarounds seem to work in Grails 4.X. I tried manually enabling and registering the converters in the same manner it was done in Grails 3 with #TestMixin, but this was a dead end for me.
Using Grails version 4.0.3.
I also opened I ticket for this towards the Grails project https://github.com/grails/grails-core/issues/11521 hoping for a long term solution to the problem or at least some documentation on how to test this common use case of Grails converters.
I'd like to make some changes to my copy of the rust standard library, then run the tests in the source files I changed. I do not need to test the compiler itself. How can I do this without testing a lot of things I am not changing and do not care about?
Here are some things I've already tried. A note - the specific file I want to play around with is libstd/io/net/pipes.rs in rust 0.12.0.
I tried rustc --test pipes.rs - the imports and options are not set up properly, it seems, and a multitude of errors is the result.
Following the rust test suite documentation, I tried make check-stage1-std NO_REBUILD=1, but this failed with "can't find crate for `green`". A person on the #rust-internals irc channel informed me that "make check-stage1 breaks semi-often as it's not the 'official way' to run tests."
Another person on that channel suggested make check-stage0-std, which seems to check libstd, but doesn't restrict testing to the file I changed, even if I use the TESTNAME flag as specified in the rust test suite documentation.
As of 2022 the way to run the test suite for the rust standard library is documented at https://rustc-dev-guide.rust-lang.org/tests/running.html .
While the documentation mentions the ability to test a single file it appears to malfunction
$ ./x.py test library/core/tests/str.rs
Updating only changed submodules
Submodules updated in 0.01 seconds
Building rustbuild
Finished dev [unoptimized] target(s) in 0.09s
thread 'main' panicked at 'error: no rules matched library/core/tests/str.rs', src/bootstrap/builder.rs:286:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00
Later on it mentions a different syntax like ./x.py test library/alloc/ --test-args str which appears to succesfully run the unit tests in library/alloc/tests/str.rs
make check-stage1-std NO_REBUILD=1 or ... check-stage2-std ... should work, if you've done a full build previously. They just build the test runner directly without doing the rest of the bootstrap.
In any case, the full std test runner is built always, since, as you noticed, the imports etc are set up for the full crate. TESTNAME is the correct way to restrict which tests are run, but there's no way to restrict tests are built.
Another option is to pull the test/relevant code into an external file, and yet another is to build the test runner by running rustc manually on libstd/lib.rs: rustc --test lib.rs. One could edit the rest of the crate to remove the tests/code you're not interested in.
I'm wondering if there is any solution to let Scala tests run automatically upon change of test class itself or class under the test (just to test automatically pairs Class <---> ClassTest) would be a good start.
sbt can help you with this. After you setup project, just run
~test
~ means continuous execution. So that sbt will watch file system changes and when changes are detected it recompiles changed classes and tests your code. ~testQuick can be even more suitable for you, because it runs only tests, that were changed (including test class and all it's transitive dependencies). You can read more about this here:
http://code.google.com/p/simple-build-tool/wiki/TriggeredExecution
http://php.jglobal.com/blog/?p=363
By the way, ~ also works with other tasks like ~run.
This is what I'm doing:
extract contents of my JRE's rt.jar
extract src.zip of my JDK (same version)
Now, if I copy Runtime.java from the extracted src folder and compile it using javac.exe without any modifications and then put it in the extracted rt folder to finally put everything back in a jar file using jar.exe, everything works as expected. The JRE runs fine.
However, if I make the slightest change to Runtime.java and compile it and put it in rt.jar, the JRE crashes whenever I attempt to start it. This is an example of a slight change that causes the silent crash:
/** Don't let anyone else instantiate this class */
private Runtime() {
System.out.println("This is a test.");
}
Instead of:
/** Don't let anyone else instantiate this class */
private Runtime() {}
Could anyone tell me why this is causing my JRE to crash?
Thanks in advance.
It's possible that System.out has not been initialised at the time that the Runtime() constructor runs. Usually console output is not considered a "slight" change, but at the wrong time it can invoke way too much stuff that may not be set up at all yet.
You're doing this all wrong. You can't distribute that modified JRE for a start, so it is only useful inside your organization . Install a SecurityManager and don't grant your codebase any of the RuntimePermissions you're trying to protect against.
#Tom - I advise you NOT to try to do this:
You cannot distribute the modified rt.jar file without violating the Sun binary license.
Even if you did, you would not be allowed to call it Java.
As you are finding, there are lots of complications that arise when you make changes, particularly when those changes might interfere with the JVM's behind the scenes initialization. And when things blow up during initialization, the JVM often cannot report the problem in an intelligible way.
If you do succeed in making the modified rt.jar work for one JRE, there is no guarantee that the same hacks will work for a different version.
Nobody in their right mind would knowingly use a modified JVM (especially one modified by a third-party) in a production app.
EDIT : judging from your other questions, I guess you are trying to reverse engineer or modify some third party Java application with a custom launcher. If you provided more information on what you were really trying to do, we might be able to suggest the right way to do it ... rather than using "desperate measures" such as modifying the JRE.
That's pretty strange, as I did the same trick with many classes in rt.jar in past.
Can you provide us with the crashed process output?