The problem is that we are an IntelliJ shop and this issue has been a thorn in our sides. It basically means that everything has to be in ./test/ in order to work. ./it/ isn't acceptable because IntelliJ picks it up as the wrong kind of source every time you try to do anything. So.... how do I separate integration tests from unit tests so that they can be run separately in Gradle if they are in the same source set? Anyone have an example?
We use the *Test*.java and *ITCase*.java naming conventions, if that helps. Anothing thing we were thinking of is some kind of use of JUnit's #Category annotation.
P.S. Please vote for this issue. It will be a thorn in the side of any IntelliJ shop considering Gradle that has integration tests in a different directory from unit tests.
I can't speak to IntelliJ configuration, but in build.gradle, if you have:
test {
if (! project.hasProperty("ITCASE")) {
exclude "**/*ITCase*"
}
}
then the following command-line would include the integration tests:
gradle test -PITCASE=true
then and the standard would exclude them:
gradle test
Related
Is there a way to build custom test phases in gradle?
I have a series of tests, namely
/unit
/local
/remote
which is running JUnit managed tests for a couple different purposes. I'd love to be able to run these as test phases, such as gradle test:unit, or something like that. Ideally, I could also specify a description for each test phase, so gradle tasks describes the role of each of the tests.
Is this possible? If so, how?
I tried this:
sourceSets {
unit {
java.srcDir file('src/test/groovy/local')
resources.srcDir file('src/local/resources')
}
}
dependencies {...}
task unitTest(type: Test){
testClassesDir = sourceSets.local.output.classesDir
classpath = sourceSets.local.runtimeClasspath
}
...as copied from withIntegrationTests in the provided samples, but when I run gradle unitTest, no tests run.
You just need to add three Test tasks (testUnit, testLocal, testRemote) and configure them accordingly. (Instead of introducing testUnit, you could also reuse the test task that comes with the Java plugin.) If the sources are in different source folders, it also makes sense to add additional source sets. For the details, have a look at samples/java/withIntegrationTests in the full Gradle distribution.
I have a Maven/Java project I've been working on for years, and I wanted to take JavaPosse's advice and start writing my tests in Scala. I've written a few tests following ScalaTest's JUnit4 quick start, and now I want these tests to be executed while running "mvn test". How should I do this? What should I put into my pom.xml to allow the tests in src/test/scala to be run side-by-side my old JUnit4 tests?
Cheers
Nik
PS, yes, I've been Googling, but all I could find on the topic were some pre-v1.0 suggestions that I didn't get working
PPS, bonus question: how can I run these tests one-at-a-time by rightclicking them in Eclipse/STS and say "Debug As... ScalaTest" or something similar where I've so far said "Debug As... JUnit Test"?
PPPS, I expect the answer has changed since July '09?
The second answer in one of the questions you linked to SHOULD work:
Is there a Scala unit test tool that integrates well with Maven?
You annotate your tests with a junit #RunWith annotation and give it the scalatest http://www.artima.com/docs-scalatest-2.0.RC3/#org.scalatest.junit.JUnitRunner
If your Tests also adhere to any naming conventions possibly enforced by Maven, this should work fine.
Note: It doesn't matter what kind of scalatest trait you use. All of them should work. If they don't and Bill Venners doesn't answer to this question, contact him on the ScalaTest mailing list.
Other Note: you can run such test suites in Eclipse using the normal JUnit plugin. But you can't run single tests, since the plugin expects to deduct a method name from the test name, which doesn't work with all types of scalatest tests.
I have been developing a project which contains a TestLauncher class that'll read a given directory and for each file it contains, run it against my tool and yield the results.
So, when coding in Eclipse, it would show up one result for each test (as expected). Today I've been toying with Intellij, and I've decided to try to run and code a bit of this project in Intellij.
When trying to run the tests, though, it seems to be only showing up 2 results instead of the 100+ it should. Although I am sure it is running the full suite, it seems to be folding all the results of a given category in a single result. That means that if I have at least one failing test in each category, it shows up as a "failed test".
I guess this must not be a bug, but rather some configuration that I am not aware about and that is on by default in Intellij but not in Eclipse. Could anyone explain what might be going on?
Edit: I am using the latest Intellij (downloaded one of these days).
Thanks
What you're seeing is simply a difference in the way the Eclipse and IDEA plug-ins are implemented. I implemented the Eclipse plug-in to be pretty clever in its display, so it will show different things depending on various factors such as the presence of a toString() method in your test class or whether your test class implements org.testng.ITest.
I suggest you ask this question on the IDEA forums and if you don't get any response, feel free to email the testng-users list and I can put you in touch with the JetBrains engineer in charge of the TestNG plug-in.
The IntelliJ-IDEA TestNG Plugin has a filter symbol called "Hide Passed" above the output Test Results. You can toggle that to display all tests, including the passed ones.
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.
If so, how? I haven't come across the proper incantation yet.
If not, what's the best approach to unit-testing Scala code from the command line? (I'm a troglodyte; I use IDEs when I have to, but I prefer to play around using Emacs and command-line tools.)
Since compiled Scala is just Java bytecode (OK, with a lot more $ characters in class names), it would be exactly as for running JUnit 4 tests against Java code, i.e. from the command line by passing the test classes as arguments to org.junit.runner.JUnitCore. As JUnit 4 out of the box only has command line support, you don't even have to worry about suppressing GUI based test runners.
That said, the specific Scala test frameworks (ScalaTest, ScalaCheck) do provide a more idiomatic set approach to testing code written in this more functional language.
You may be interested in ScalaTest.
ScalaTest is a free, open-source
testing tool for Scala and Java
programmers. It is written in Scala,
and enables you to write tests in
Scala to test either Scala or Java
code. It is released under the Apache
2.0 open source license.
Because different developers take
different approaches to creating
software, no single approach to
testing is a good fit for everyone. In
light of this reality, ScalaTest is
designed to facilitate different
styles of testing.
See the Runner documentation for how to run tests from the command line.
The suggestion of ScalaTest -- or any of the other Scala-specific frameworks, for that matter, is very good. I'd like to point to something else, though.
SBT.
SBT is a build tool, like Ant, Maven or Make. One interesting aspect of it, which will matter to us, is that it is Scala-based. I don't mean it has special capabilities to handle Scala code or that it is written in Scala, though both these things are true. I mean it uses Scala code, instead of XML like Maven and Ant, as the configuration source.
That in itself is interesting. Just today I saw a wonderful example of separating test sources from program sources, which I post here just because its so cool.
// on this project we keep all sources, whether they be Scala or Java, and whether they be
// regular classes or test classes, in a single src tree.
override def mainScalaSourcePath = "src"
override def mainJavaSourcePath = "src"
override def testScalaSourcePath = "src"
override def testJavaSourcePath = "src"
override def mainResourcesPath = "resources"
// distinguish main sources from test sources
def testSourceFilter =
"Test*.scala" | "Test*.java" |
"AbstractTest*.scala" | "AbstractTest*.java" |
"ScalaTestRunner.scala"
def mainSourceFilter = ("*.scala" | "*.java") - testSourceFilter
override def mainSources = descendents(mainSourceRoots, mainSourceFilter)
override def testSources = descendents(testSourceRoots, testSourceFilter)
But what makes it even more interesting is that SBT works like a console. You run "sbt", and you get dropped into a console-like interface, from which you can type commands like, for instance, "test", and have your tests run.