I have a gradle project with 2 Test tasks, test and test2.
When running gradle test test2 2 times both test and test2 ran again even though they should be UP-TO-DATE(when running gradle test It stays UP-TO-DATE no matter how many times I ran it).
Why is this happening?
After trying to recreate this error on another computer I found out that.
This error occurred on gradle 2, on gradle 3 It was OK.
This must have something to do with this link
What I think is happening
It seems that on gralde 2 the test results where exported to $buildDir/test-results and then the UP-TO-DATE function wouldn't work because the second Test tasks changed the output directory, which gives this directory structure:
build
test-results
binary
test/...
test2/...
TEST-MyTest1.xml
TEST-MyTest2.xml
And on gradle 3 the results are exported to $buildDir/test-results/$taskName, which gives this directory structure:
build
test-results
test
binary/...
TEST-MyTest1.xml
test2
binary/...
TEST-MyTest2.xml
P.S. If I am wrong please let me know
Related
First of all, my terminology may be incorrect with some of these terms as I am very new to jest so if that is the case I would love to be corrected to help me learn.
In case I am using the jest terminology incorrectly, here is what I mean:
Test Suite - The entire group of test files I am attempting to run
Test File - The actual .js test file that is being run
Test - The individual 'it' code blocks in each test file.
Currently, I am using a group of around 20 jest tests to test my API EPs for my SQL Server and its corresponding linked server.
To do this, I run an npm command like so in the terminal.
npm run test:file ape/linked -- --env=monke.env
With how jest currently is working, if one of tests in the 20 test files fails, then it quits out of the test suite entirely.
I would like it to just fail out of whatever test file it is in, then continue to the next text file.
I know jest currently has the --bail flag, but enabling this continues the same test file on failure which I can't have happen due to the nature of my linked server to my actual SQL server.
Any help would be greatly appreciated and I am new to all of this so let me know if more info needs to be included.
This will be running on various mac versions as well as Ubunutu server
I check out the source code of Cassandra, and I want to run a unit test case in debug mode to understand how it works
Below is my JUnit run configuration set up. The code can compile correctly using ant. And I tried both targets build and build-test.
IntelliJ can pick up the class in the run configuration, but when I run this profile, I got.
Process finished with exit code 1
Class not found: "org.apache.cassandra.tools.SSTableExportTest"
Empty test suite.
What part do I need to change the configuration so that IntelliJ can run this unit test cases?
Since you're trying to debug Cassandra. You can reference https://wiki.apache.org/cassandra/RunningCassandraInIDEA. They have already set up a ant target to generate required configurations.
Using gradle 2.2.1 and com.android.tools.build:gradle:1.5.0
When I run ./gradle build in the console the build fails at step :testDebugUnitTest.
It fails because it tries to run a InstrumentationTestCase that should not happen.
What am I missing here?
This is normal. It's because build depends on other tasks. You can see these tasks by running gradle tasks --all.
For build it will show this: build - Assembles and tests this project. [assemble, check].
The check task is configured like this: check - Runs all checks. [assembleDebug, lint, test]
The test task like this: test - Run unit tests for all variants. [testDebugUnitTest, testReleaseUnitTest]
And that is why you see the testDebugUnitTest show up when you run the build task.
So if you just want to build without testing, you need to run gradle assemble. And if you want to save time and only build the variant you need, you can run gradle assembleDebug, for example.
I am creating a TeamCity build configuration with a few steps. One of those steps is running tests using MSTest. Currently, my tests are failing (by design so I can test the build process), but the build steps after the step for running the tests happen, even though I can see the test process exits with code 1 (ie, something other than code 0) in the build log. It does mark the build as failed, but I'd prefer it if the steps in the build stopped once failing tests were detected. Is that possible and I'm just missing something in the configuration?
When you create build step there are select Execute step for execution policy. Where you should select Only if all previous steps were successful.
Here is it:
But in your case there are bug in the MsTest and NUnit build steps. Here is workaround. And here is related issue.
I'm running TeamCity 6.5 on a Windows Server, with a couple of build agents on the same server (all running as the system user as services). I had been building SilverLight projects and running the StatLight (v 1.4.4147) tests previously under Jenkins with no problems. On Jenkins, I called the StatLight test in a custom script as follows:
StatLight.exe -x="Tests.xap"
StatLight.exe -x="MoreTests.xap"
StatLight.exe -x="EvenMoreTests.xap"
... etc., but when I migrated my build jobs to TeamCity, I also changed these into a single command line step as follows:
StatLight.exe --teamcity -x="Tests.xap" -x="MoreTests.xap" -x="EvenMoreTests.xap"
This works about 50% of the time, but when it fails, there's no output in the build log to tell me why - I just get:
[11:41:18]: [MyProject\bin\Release\MoreTests.xap] Tests.ExtensionsTests.WatchObservableCollection
[11:41:18]: [MyProject\bin\Release\MoreTests.xap] Tests.SubscribingModelBaseTests.DisposeIsCalled
[11:41:18]: [MyProject\bin\Release\MoreTests.xap] --- Completed Test Run at: 28/09/2011 11:41:18. Total Run Time: 00:00:11.8125000
[11:41:19]: [MyProject\bin\Release\MoreTests.xap] Test run results: Total 6, Successful 6, Failed 0,
[11:41:19]: [Step 5/6] MyProject\bin\Release\EvenMoreTests.xap (9m:42s)
... and then nothing more. The time reported in that last line just goes up and up until I kill the the build job. Adding the --debug switch to StatLight doesn't improve the above output either.
Right now, I've switched the TeamCity build step to call each test individually as I was in Jenkins, but this is more of a workaround than a proper solution. And of course, I may still run into the above problem - I've yet to find out.
What I'd like to know is what steps I can take to debug this issue properly, or whether there are known issues that can cause the above behaviour?
There was one issue fixed in the 1.5 version relating to teamcity. http://statlight.codeplex.com/workitem/13654
I'm not sure it will fix your issue, but would you mind upgrading, trying and reporting back?