I am working with chisel-template
In my src/main/scala I have two folders, let say A and B.
In src/test/scala, I have a folder for A and a folder for B.
I want to test only A but when I do
$ sbt "test:runMain A.TestMain"
I have the errors of B which make the compilation fail. I know there are problems in B but I just want to check A first.
How can I test or compile only one folder ?
Thanks !
I don't think there is a way to do this. But if you use scalatest to launch your tests instead of a main it's fairly easy.
You can specify just the path you want with testOnly for example, from sbt command line
testOnly A.*
Or from the shell command line
sbt 'testOnly A.*'
In fact, with tests you can even specify specific tests within a test harness by using
sbt 'testOnly A.* -- -z "dog"'
(notes, the quoting is significant),
you can run only those tests in package a that have the word dog in the test name
I'm a beginner of scala, so there may be better ways.
sbt ReferenceManual tells us to add statement like below in build.sbt
excludeFilter in unmanagedSources := "excludedFileName"
If you want to exclude files only when running test, you can specify it like below.
excludeFilter in (Test, unmanagedSources) := "excludedFileName"
Probably, your question is about sbt, not chisel. That's why you may get better and more detailed answer if you add scala tag.
Related
I plan to use the Azkaban https://azkaban.github.io/ for running batch jobs. According to CI ideas we have few environments like dev, test, stage, production and of course job should have different configuration for each environment.
According to Azkaban documentation http://azkaban.github.io/azkaban/docs/latest/#job-configuration Azkaban allows for replacing of parameters whenever a ${parameter} is found. And solution looks like:
system.properties
myFlow/
dev.properties
....
prod.properties
foo.job
#system.properties
env=dev
#dev.properties
dev.database=localhost:2181
#prod.properties
prod.database=aws:port
#foo.job
some command --db ${${env}.database}
And later on each environment we can override the env variable. From my point of view this solution looks strange. Can I just say to Azkaban which property file should be used on environment?
What is the best approach to do it?
An other approach can be found here https://github.com/azkaban/azkaban/issues/1545#issuecomment-339750417
Using ammonite 0.7.0 using cd! in scripts would change you to that directory and execute the following bit of code, which was great as i've been using ammonite for build & deploy of a scala project.
But in 0.7.8 this does not work any longer, it fails like...
cat TestCd.sc
import ammonite.ops._
import ammonite.ops.ImplicitWd._
cd! root/'Users/'jeff
Error:
TestCd.sc:4: not found: value cd
val res_2 = cd! root/'Users/'jeff
I can make it work in this (very) small test by changing the code to import and instantiate a ammonite.shell.ShellSession, but that leads to other issues.
I've asked on gitter and in github issues, thought i'd cast a wider net as i've not received responses.
Thanks in advance, i don't want to stay on an old version or rewrite the deployment script in a more mature scripting language, as I'm using scala for other things, and feel this is critical to writing shell scripts in any language.
Jeff
While it would be nice if this just worked. An item I missed is that you can install a custom ~/.ammonite/predefScript.sc, and this is how i've gotten around the issue. The contents is identical to predef.sc without the final line. Feel free to grab it from this gist if you need this as well.
predefScript.sc - Gist
Add it to your system with
mkdir -p ~/.ammonite && curl -L -o ~/.ammonite/predefScript.sc https://git.io/v1vv7
I'm trying to make my tasks run tests in a certain directory. I was looking at sourceSets, however I inferred that they are useful if you are running outside the test/groovy folder. All of my tests are within the test/groovy folder.
I've got a set of Geb tests as well as a set of service tests. I would like to run them both together and independently. Essentially my tree structure would look like this, being able to run all tests.
Test
--gebTest
----firefoxTest
----chromeTest
----ieTest
--servicesTest
----service1Test
----service2Test
----service3Test
----etc.
My file structure is as follows:
project
-src
--test
---groovy
----com
-----acme
------functional <---where my geb tests sit
------services <---umbrella for services
-------service1 <---each unique service
-------service2
-------service3
-------etc
Can anyone lend me a hand. For the life of me I don't know how Gradle picks what tests to execute.
Thank you in advanced.
SourceSets are indeed a solution to your problem, but I notice you only differentiate your tests by their package names. I'm not sure but that may prove problematic with source sets.
Personally I would prefer a directory structure like this anyway
src
-test
--groovy
---functional
----com etc
---services
----com etc
However, if you are attached to your current structure then take a look at Gradle's test filtering support, which will allow you to filter by package name.
http://www.gradle.org/docs/current/userguide/java_plugin.html#sec:java_test
I was trying to add some automated Unit Tests to my project with Bamboo and have been facing some problems. The Unit Tests themselves are done with googletest, which creates an XML file which should be compatible with the JUnit parser.
However, I'm getting the following error when executing Bamboo's JUnit Parser:
02-Apr-2013 12:11:22 Starting task ''Parse UnitTest output' of type 'com.atlassian.bamboo.plugins.testresultparser:task.testresultparser.junit'
02-Apr-2013 12:11:22 Parsing test results...
02-Apr-2013 12:11:22 Failing task since test cases were expected but none were found.
02-Apr-2013 12:11:22 Finished task 'Parse UnitTest output'
This doesn't seem to have anything to do with the .xml file itself, as I've tried a few. This included my own output.xml, generated by googletest and the sample outputs from https://confluence.atlassian.com/display/BAMBOO/JUnit+parsing+in+Bamboo.
I also adapted said files against the two proposed .xsd files, which should match the output that the JUnit Parser expects, but all to no effect.
Update:
Up until now I told the JUnit Parser to look for ${bamboo.build.working.directory}/output.xml
When I tried **/*.xml it worked.
As I understand it now, after very carefully reading the task description, I have to give it a folder. But I can also give it the files, if I do it in ant-style (with a glob?). This is at the very least very confusing and still doesn't fully answer the inital question. So if anyone could enlighten me, please do.
This is a super-old question, I figured I'd add an answer for posterity. As a few people have commented, the configuration value for test output files requires a relative path. The question is, relative to what?
I think the answer to that depends on how you have your source repositories configured, but in general it will be relative to the root of your project. If all else fails, look at where bamboo is putting your source code when it gets checked out; that'll be the directory to which bamboo appends the test output search path.
For the configuration syntax, you're correct that ant-style patterns can be used (Learning Ant path style for reference).
Just as an example, if you have a project which on your local machine lives at C:\git\MyProject, and your test results end up at C:\git\MyProject\Output\Tests\output.xml, then you'd specify Output/Tests/output.xml in the 'Specify custom results directories' field of the appropriate task configuration. You could also use Output/**/*.xml to search for all .xml files in the Output directory.
I have a test setup for a cloud system that uses a mixture of python for process level control and junit for internal state inspection. Essentially, I bring up several VMs to server as the cloud and then a junit VM which is a member of the cloud but drives tests and checks internal state. Our existing cloud management stuff is driven by python and I would like to maintain this.
I have a working setup that will run the JUnit command line via
java -ea -cp <classpath> org.junit.runner.JUnitCore <tests>
but this does not produce an report file. I know that ant is capable of producing an xml report, but I do not want to involve ant in this process (I have enough moving parts already).
Is there a way to launch junit from the command line such that it produces a report?
Ideally, I would have the junit tests produce xml reports, the python tests produce xml reports, and then merge them together for consumption by our CI system.
Update: The command line execution must support Windows, Linux, and Mac. We are not allowed to ship an external ant, although packaging an internal ant might be an option.
The JUnit library does not have any XML output options. To achieve such a thing, you'll need to write your own RunListener, which listens for the output and will in your case write the XML file.
However, to get the XML file in the correct format so that it can be read by CI system, I think it would be far easier to just use ant, either via the command line using a build.xml (JUnitReport), or using the java api: How can i use Apache ANT Programmatically.
EDIT: Initially, we had four options:
Use ant from the command line
Use ant programmatically (using the Java API)
Use the XMLJUnitResultFormatter directly with JUnitCore
Create a custom RunListener which produces the correct XML output.
Given the restrictions added by the OP, we can't use ant from the command line, which eliminates 1.
After looking more closely at the Ant JUnit task, it seems to be impossible to use this with JUnitCore (adding a TestListener), because ant uses the name of the test class directly, so you can't do a bridge class. From XMLJUnitResultFormatter.java
private void formatError(String type, Test test, Throwable t) {
...
nested.setAttribute(ATTR_TYPE, t.getClass().getName());
String strace = JUnitTestRunner.getFilteredTrace(t);
Text trace = doc.createTextNode(strace);
nested.appendChild(trace);
}
This eliminates 3.
Invoke Ant programmatically, via the Java API. I can't find any recent documentation on this. This seems to be hard.
So, finally, I would do 4, a custom RunListener, using the code from XMLJUnitResultFormatter as a base. And then, I'd publish it on github.com, so this question could be answered properly :-)