Is it possible to make sbt stop at the first failed test?
For example, during a refactoring, I'd use that feature like this:
~quickFailTest
and I'd fix test after test.
Related
I am doing the Pintos project on the side to learn more about operating systems. I had tons of devops trouble at first with it not running well on an 18.04 Ubuntu droplet. I am now running it on the VirtualBox image that UCCS tells students to download for pintos.
I finished project 1 and started to map out my solution to project 2. Following the instructions to create a file I ran
pintos-mkdisk filesys.dsk --filesys-size=2
pintos -- -f -q
but am getting error
Kernel PANIC at ../../threads/vaddr.h:87 in vtop(): assertion
`is_kernel_vaddr (vaddr)' failed.
I then tried running make check (all the tests). They are all failing for the same reason.
Am I missing something? Is there something I need to implement to fix this? I reread the instructions and didnt see anything?
Would appreciate help!
Thanks
I had a similar problem. My code for Project 1 ran fine, but I could not format the filesystem for Project 2.
The failure for me came from the following call chain:
thread_init() -> ... -> thread_schedule_tail() -> process_activate() -> pagedir_activate() -> vtop()
The problem is that init_page_dir is still NULL when pagedir_activate() is called. init_page_dir should have been initialized in paging_init() but this is called after thread_init().
The root cause was that my scheduler was being called too early, i.e. before the call to thread_start(). The reason for my problem was that I had built in a call to thread_yield() upon completion of every call to lock_release() which makes sense from a priority donation standpoint. Unfortunately, locks are used prior to the scheduler being ready! To fix this, I installed a flag called threading_started that bails in the first line of my thread_block() and thread_yield() functions if thread_start() has not yet been called.
Good luck!
I've found the sbt-groovy plugin and it properly compiles both the test and the main sources just fine. However, the definedTests key is always empty; SBT never discovers any groovy tests. I've verified this with a very simple single src/test/groovy/Test.groovy with a single method annotated #Test which should be picked up by the junit-interface.
I think the root of the issue is that the sbt-groovy plugin needs to define the task "definedTests" in its own plugin source code. This task provides a Seq[TestDefinition].
Looking at how SBT itself populates the sequence reveals it uses additional output from the scala compiler (which also happens to compile java files, so it works out of the box for java) in an Analysis class which is populated by output from the IncrementalCompiler
I've fiddled around with the taskdef, but I'm not sure I'm even on the right path. Documentation on this stuff is pretty sparse, or heavily connected to the IncrementalCompiler.
What code do I need in sbt-groovy to produce a Seq[TestDefinition] that satisfies SBT so that I can run tests (picked up by the junit-interface) that are written in Groovy?
The test detection code is in Tests.discover, which you might be interested in.
It seems like all you need is the list of methods with annotations and list of subclasses.
If you have some way of finding them out, you probably could mimic what's going on in the code.
The discovery code, as you mentioned, relies on the the Analysis datatype, which is the inner gut of
the incremental compiler. You might be able to take advantage of the fact that it is
sbt (not Scala or Java compiler) that is responsible for incremental compilation.
For Java compilation, AnalyzingJavaCompiler.compile calls the compiler and then does the analysis.
In theory, you could define an AnalyzingGroovyCompiler that uses the same mechanism
as the one used for the Java compilation. This is not exactly a walk in the park since
some of the parts are hidden behind private[sbt].
Long story short, I put together a hacky proof-of-concept that wrangles the incremental compiler into generating Analysis for Groovy code, and was able to detect a test.
https://github.com/eed3si9n/sbt-groovy-test
I've only tested with one simple use case
import org.junit.Test
import org.junit.Assert
class Foo {
#Test
public void foo() {
Assert.assertEquals(1, 2)
}
}
Running test from sbt yeilds the following output:
> test
[info] Start Compiling Test Groovy sources : /Users/xxx/sbt-2167-groovy/src/test/groovy
[error] Test Foo.foo failed: expected:<1> but was:<2>, took 0.062 sec
[error] Failed: Total 1, Failed 1, Errors 0, Passed 0
[error] Failed tests:
[error] Foo
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 1 s, completed Aug 23, 2015 5:05:01 AM
It might not work with future versions of sbt. Caveat emptor.
Is it possible that Qt only outputs the Unit Tests that have failed?
Right now I get a huge list that 140 have been passed and 3 have failed. I would like to only see the ones that have failed.
Use the -silent command line option. It only shows fatal errors, test failures and minimal status messages.
Our automated build process incorporates a grunt task that periodically (more times than I'd like) generates a 6 return code.
According to the grunt web page 6 is a "Warning". Well okay, a warning for what? It's breaking our build since we would only pass on a 0 exit case. I'm looking at wrapping this in a script so I can catch this warning condition and generate a success exit code, though without any idea what the Warning might be I'm hesitant. It appears to work when I get this exit condition but would like a better understanding on what it may be.
Any ideas?
So this turned out to be an issue with grunt-contrib-less. I didn't recognize the associated less compiler error in our build log:
[39mnon_object_property_loadError: Cannot read property 'rules' of undefined in ../../XXXX/styles/modules/SomeLessFile.less on line null, column 0: [31m
Once I found this line a google search quickly found this in GitHub:
And have updated the grunt-contrib-less package. So far so good.
check http://gruntjs.com/api/grunt.fail:
If --stack is specified on the command-line and an error object was
specified, a stack trace will be logged.
Or try to run "grunt --verbose --force"
I'm supposed to run some jbehave(automated) tests in bamboo. Once the tests run I'll generate some junit compatible xml files so that bamboo could understand the same. All the jbehave tests are ran as part of a script, because I need to run the jbehave tests in a separate display screen(remember these are automated browser tests). Example script is as follows.
Ex:
export DISPLAY=:0 && xvfb-run --server-args="-screen 0, 1024x768x24"
mvn clean integration-test -DskipTests -P integration-test -Dtest=*
I have one more junit parser task which points to the generated junit compatible xml files. So, once the bamboo build runs and even if all the tests pass, I get red build with the message "No failed tests found, a possible compilation error occurred."
Can somone please help me on this regard.
Your build script might be producing successful test reports, but one (or both, possibly) of your tasks is failing. That means that the failure is probably* occurring after your tests complete. Check your build logs for errors. You might also try logging in to your Bamboo server (as the bamboo user) and running the commands by hand.
I've seen this message in the past when our test task was crashing halfway through the test run, resulting in one malformed report that Bamboo ignored and a bunch of successful reports.
*Check the build log to make sure that your tests are indeed running. If mvn clean doesn't clean out the test report directory, Bamboo might just be parsing stale test reports.
EDIT: (in response to Kishore's links)
It looks like your task to kill Xvfb is what is causing the build to fail.
18-Jul-2012 09:50:18 Starting task 'Kill Xvfb' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.script'
18-Jul-2012 09:50:18
Beginning to execute external process for build 'Functional Tests - Application Release Test - Default Job'
... running command line:
/bin/sh
/tmp/FUNC-APPTEST-JOB1-91-ScriptBuildTask-4153769009554485085.sh
... in: /opt/bamboo-home/xml-data/build-dir/FUNC-APPTEST-JOB1
... using extra environment variables:
<..snip (no meaningful output)..>
18-Jul-2012 09:50:18 Failing task since return code was 1 while expected 0
18-Jul-2012 09:50:18 Finished task 'Kill Xvfb'
What does your "Kill Xvfb" script do? Are you trying something like pkill -f "[x]vfb"? pkill -f silently returns non-zero if it can't match the expression to any processes.
My solution was to make a 'script' task:
#!/bin/bash
/usr/local/bin/phpcs --report=checkstyle --report-file=build/logs/checkstyle.xml --standard=PSR2 ./lib | exit 0
Which always exits with status 0.
This is because PHP code sniffer return exit status 1 when only 1 coding violation (warning / error) is found which causes the built to fail.
Turns out to be a simple fix.
General bamboo behavior is to scan the entire log and see for any failure codes(1). For this specific configuration i had some 6 scripts out of which one of them was to kill the xvfb(frame buffer). For some reason server is not able to kill xvfb and that task was returning a failure code. Because of this, though all the tests passed, bamboo got one of this error codes from previous tasks and build was failing.
Current fix is to remove the task which kills xvfb and the build went green! \o/.