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
Related
I'm using Cypress to run a suite of automated tests.
The current version of cypress provides mocha-junit-reporter out of the box, and provides configuration options to pass to the reporter. One of the options is the 'mochaFile'.
I'm using the recommended [hash] tag to output reports across multiple spec files.
this results in a flat mess of files that look like 'results/test-output-abc12345.xml'.
What I want instead is for the test file's relative path and filename to be pass in as the reporter's output file path.
This would give me a structured, feature first view of the output, and in Azure Dev Ops, which aggregates the test output, it would give me correct filenames to detect intermittently failing tests.
Things I've tried that haven't worked:
I've tried to use hooks to modify Cypress's config or set environment variables to try to override the reporterOptions/mochaFile per test at (hopefully) the right time.
I've tried to grab the outputted defaultly-named xml file, and copy it to the correct path+filename given the Cypress.spec.name context, but I can't seem to find the right hook or time to do this.
after and afterEach don't work - I don't think the test report has saved the file yet.
Using a plugin, hooking to some event on test:before:run or test:after:run seem promising, but I'm flying blind since I can't debug into it, so I've been unsucessful in modifying the reporter's output path or copying the file.
I'd love it if someone could show a working example using mocha-junit-reporter, or even a different mocha compatible reporter, if the reporter would play well with Azure Dev Ops, and can help me discover intermittently failing tests.
I was trying to integrate my cucumber tests with maven-cucumber-reporting(from masterthought.net). I downloaded their Jenkins plugin and incorporated in my pom.xml file.
I have 2 tests in my eclipse project and when I ran these tests though maven it gets executed successfully. But, when I see my HTML report and also the cucumber.json , it displays details of only one test case.
I have been using Cucumber-JVM
Can you please let me know if I'm going wrong somewhere.
Thanks,
Prashanth
Do you have two RunCukesTest files for your two tests? If so make sure that you are creating unique json files for each tests (Note Test1.json below, make sure you have that distinction for each of your tests). Otherwise they will be overwritten by each other and you will only see the results from your last test.
#Cucumber.Options(format = { "pretty", "html:target/cucumber-html-report",
"json-pretty:target/Test1.json" },
features = { "src/test/resources/features" })
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 am porting over an MSBuild script from CCnet to run in Jenkins. The MSBuild project is used to create a deployment package. I would rather have Jenkins drive this process itself but that's a longer term aim.
The problem i am having is (as in the title) when we try and use the HgPull target, from the MSBuild mecurial task (http://msbuildhg.codeplex.com/) we get the error message
HgProcessException: The command hg.exe is not available [Path to project]
I have seen on the project web site that someone solved it by adding the LibraryLocation proeprty to the target but that seems to have made no difference. My target currently looks like this:
Target Name="UpdateSources">
<HgPull
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Force="true"
Update="true"
LocalPath="$(SourcePath)"
/>
<HgUpdate
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Clean="true"
LocalPath="$(SourcePath)"
/>
I'm rather at a loss. Please let me know if you need any more information added to this post to solve this issue. I'm really quite new to MSBuild so really not sure where to start investigating this.
EDIT:
One thing i forgot to mention was that i have tried running the MSbuild command in a console window on the build server and still get the same result. This is really odd given it works fine in CCNet, what magic is CCNet doing to make this command work?
This is now resolved, unfortunately i'm not sure what changes i made to correct these. I believe it may have been down to path separators and whether they where trailing or not in another part of the config file. It does so annoy me with the lack of resilience/consistency between applications where you need to specify paths with/without trailing slashes.
Just a thought, but try adding 'C:\Program Files\TortoiseHg' to your system path. Maybe CCNet has it specified somewhere that Jenkins doesn't have access to.
Also, just for sanity's sake, verify that hg.exe actually exists at that location.
I have a couple of test files written in my DSL in my tests plugin/project. Most of the tests use inline multi-line strings and Xtend but in four cases, I need to test code which does some magic with URLs and the classpath, so I really need resources in the classpath for that.
Since loading the resources only works when the extension is correct, I can't give the files a fake extension.
Now my problem: My DSL also has a code generator. This means that eventually, I end up with a couple of generated files in places where I can't have them (they don't compile, for example, and one even contains an error to test error handling when information is split across several files).
I can't disable the Xtext nature because the tests project uses Xtend so for these files, I do need code generation.
Since the generator runs inside Eclipse (I have the DSL plugins installed for other projects), there is no way to override the code generator in Guice.
How can I disable the code generator in this case?
There is a simple way to achieve this:
Open the properties of your project
Expand the entry for your DSL
Select "Compiler"
Select "Enable project specific settings"
Disable/deselect "Compiler is activated" under "General"
If you don't have a properties entry for your DSL:
Add this fragment to your .mwe2 workflow file:
fragment = generator.GeneratorFragment {}
Regenerate your projects
Merge the new code from plugin.xml_gen into plugin.xml both in the base and the UI plugins.
The interesting parts are the two extension points org.eclipse.ui.preferencePages and org.eclipse.ui.propertyPages