Just like the title says. Do before/after/beforeEach/afterEach hooks in Mocha work even if tests fail?
Yes, they do run even if the test fail.
However, if you run Mocha with the bail option, the teardown hooks will not run.
Just did an quick check with existing test suites here.
The code:
setup(function() {
console.log("1");
});
teardown(function() {
console.log("2");
});
The executions:
D:\Dev\JS\toposort>mocha
Toposort
◦ should sort correctly: 1
√ should sort correctly
2
◦ should find cyclic dependencies: 1
1) should find cyclic dependencies
2
◦ #2 - should add the item if an empty array of dependencies is passed: 1
√ #2 - should add the item if an empty array of dependencies is passed
2
2 passing (15 ms)
1 failing
1) Toposort should find cyclic dependencies:
AssertionError: expected [Function] to not throw 'Error' but [Error: Cyclic dependency found. '3' is dependent of itself
.] was thrown
D:\Dev\JS\toposort>mocha --bail
Toposort
◦ should sort correctly: 1
√ should sort correctly
2
◦ should find cyclic dependencies: 1
1) should find cyclic dependencies
1 passing (14 ms)
1 failing
1) Toposort should find cyclic dependencies:
AssertionError: expected [Function] to not throw 'Error' but [Error: Cyclic dependency found. '3' is dependent of itself
.] was thrown
Related
We have the following output at the end of our Jest test base:
Test Suites: 273 passed, 273 total
Tests: 1 skipped, 1923 passed, 1924 total
Snapshots: 61 passed, 61 total
Time: 38.885 s, estimated 39 s
You see there is one skipped test.
When I search my test files either for it.skip or test.skip or generally skip I find nothing.
What I also tried is outputting the test run into JSON via:
jest --json --outputFile=testrun.json
In the top of the file I find this information:
{
"numFailedTestSuites": 0,
"numFailedTests": 0,
"numPassedTestSuites": 273,
"numPassedTests": 1923,
"numPendingTestSuites": 0,
"numPendingTests": 1,
"numRuntimeErrorTestSuites": 0,
"numTodoTests": 0,
"numTotalTestSuites": 273,
"numTotalTests": 1924,
...
}
so it looks like that numPendingTests is the one pointing to the skipped one. But when I search the output file, again, no trace of a skipped test. In fact, I did a search for "status": "[a-z]and there is no other status to be found than passed.
Short of looking through 270+ test suites, how else could a skipped test hide from me? Is there any way to find it?
As mentioned by johnrsharp as a comment, another way to skip tests in Jest is to prefix the term it(test) with x- so if you want to scan the files for skipped tests, you also need to look out for xit or xtest.
I am trying to get Robotframework(Ride) work with KiwiTCMS.
I am making the connection to the KIWI server (local) but I am getting these errors that I am not sure where(In RIDE? or the .conf file?) to fix:
[ ERROR ] Calling method 'start_suite' of listener 'zealand.listener.KiwiTCMS' failed: ENVIRONFILE Version value not defined, missing one of TCMS_PRODUCT_VERSION, TRAVIS_COMMIT, TRAVIS_PULL_REQUEST_SHA or GIT_COMMIT
[ ERROR ] Calling method 'end_test' of listener 'zealand.listener.KiwiTCMS' failed: TypeError: 'NoneType' object is not subscriptable
TestKiwiRide | PASS |
------------------------------------------------------------------------------
KiwiTest.TestKiwi | PASS |
1 test, 1 passed, 0 failed
==============================================================================
KiwiTest | PASS |
1 test, 1 passed, 0 failed
==============================================================================
Output: C:\Users\hendri\Documents\KiwiTest\output.xml
Log: C:\Users\hendri\Documents\KiwiTest\log.html
Report: C:\Users\hendri\Documents\KiwiTest\report.html
(kiwi-env) C:\Users\hendri\Documents\KiwiTest>
Please assit?
Details goes into the bat file you use to call the test cases
check here : https://kiwitcms.readthedocs.io/en/stable/plugins/automation-frameworks.html
In plugin configuration section, you have to passe configuration as environment variables. e.g.
export TCMS_PLAN_ID=*PLAN_ID*
I have a rust lib that I compile with cargo and the resulting binary should bundle a folder of json files. Those json files are read by my program via:
let filename = "./fonts/console.json";
let data = read_to_string(Path::new(filename).as_os_str())
.unwrap_or(format!("Unable to read file \"{}\"", color(filename, Colors::Red)));
serde_json::from_str(&data).unwrap_or_else(|error| {
panic!(
"JSON parsing error encountered for: \"{}\"\nError: {}",
color(filename, Colors::Red),
color(&format!("{}", error), Colors::Yellow)
)
})
When I run cargo build --release I get a binary that I run with like this:
λ my_thing test
test
And the code path for the rust code above is triggered without any errors.
I also like to add that cargo install mything works as expected as well. No issues which makes me think this is not a cargo bundle compile issue...?!
Now I'm trying to publish this lib on homebrew so I wrote this formula:
class Mything < Formula
desc "Description etc"
homepage "https://hpomepage.com"
url "https://github.com/path/to/archive/refs/tags/v3.0.0.tar.gz"
sha256 "547a8e3059e1543debd8e0f10e9efd05c27d13b0717echs7634e1c4cf49d44cb"
license "GPL-3.0-or-later"
depends_on "rust" => :build
def install
chdir "rust" do
system "make"
system "cargo", "build", "--release", "--bin", "mything"
bin.install "target/release/mything"
end
end
test do
print "#{bin}/mything test -f console\n"
# ^-- I added this for debugging to make 100% sure I'm not getting the binaries mixed up
assert_match "\n\n\ntest\n\n\n",
shell_output("#{bin}/mything test -f console")
end
end
Installing this works fine but when I run brew test mything I get:
λ brew test mything
==> Testing mything
/opt/homebrew/Cellar/mything/3.0.0/bin/mything test -f console
==> /opt/homebrew/Cellar/mything/3.0.0/bin/mything test -f console
thread 'main' panicked at 'JSON parsing error encountered for: "./fonts/console.json"
Error: expected value at line 1 column 1', src/font.rs:88:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: mything: failed
An exception occurred within a child process:
Minitest::Assertion: Expected: 0
Actual: 101
/opt/homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/minitest-5.15.0/lib/minitest/assertions.rb:183:in `assert'
/opt/homebrew/Library/Homebrew/vendor/bundle/ruby/2.6.0/gems/minitest-5.15.0/lib/minitest/assertions.rb:218:in `assert_equal'
/opt/homebrew/Library/Homebrew/formula_assertions.rb:26:in `shell_output'
/opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/mything.rb:21:in `block in <class:Mything>'
/opt/homebrew/Library/Homebrew/formula.rb:2112:in `block (3 levels) in run_test'
/opt/homebrew/Library/Homebrew/utils.rb:595:in `with_env'
/opt/homebrew/Library/Homebrew/formula.rb:2111:in `block (2 levels) in run_test'
/opt/homebrew/Library/Homebrew/formula.rb:948:in `with_logging'
/opt/homebrew/Library/Homebrew/formula.rb:2110:in `block in run_test'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `block in run'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
/opt/homebrew/Library/Homebrew/mktemp.rb:63:in `run'
/opt/homebrew/Library/Homebrew/formula.rb:2363:in `mktemp'
/opt/homebrew/Library/Homebrew/formula.rb:2104:in `run_test'
/opt/homebrew/Library/Homebrew/test.rb:43:in `block in <main>'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:93:in `block in timeout'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `block in catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:33:in `catch'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/timeout.rb:108:in `timeout'
/opt/homebrew/Library/Homebrew/test.rb:48:in `<main>'
Now I copy the printed first line of that output and run it the same way:
λ /opt/homebrew/Cellar/mything/3.0.0/bin/mything test -f console
test
And it works. That's the very same binary that brew is testing here.
I don't know much ruby so there is a good chance I'm getting the test wrong somehow?
I also tried to do this in the test:
system bin/"cfonts", "test", "-f", "console"
Which also fails with the same error.
When I run that binary now since it's installed via brew and in my PATH it all works as well which is nuts...
λ mything test -f console
test
λ which mything
/opt/homebrew/bin/mything
Any help is appreciated.
The issue was that of course the relative path was only working in certain directories where that folder was present.
A rust issue after-all.
So I used the include_str macro to include the contents of the json file into the binary at compile time:
let font_content = include_str!("../fonts/console.json");
serde_json::from_str(&font_content).unwrap_or_else(|error| {
panic!(
"JSON parsing error encountered for: \"{}\"\nError: {}",
color(filename, Colors::Red),
color(&format!("{}", error), Colors::Yellow)
)
})
Now the brew formula works fine:
class Mything < Formula
desc "Description etc"
homepage "https://hpomepage.com"
url "https://github.com/path/to/archive/refs/tags/v3.0.0.tar.gz"
sha256 "547a8e3059e1543debd8e0f10e9efd05c27d13b0717echs7634e1c4cf49d44cb"
license "GPL-3.0-or-later"
depends_on "rust" => :build
def install
chdir "rust" do
system "make"
system "cargo", "build", "--release", "--bin", "mything"
bin.install "target/release/mything"
end
end
test do
assert_match "\n\n\ntest\n\n\n",
shell_output("#{bin}/mything test -f console")
end
end
λ brew test cfonts
==> Testing cfonts
==> /opt/homebrew/Cellar/mything/3.0.0/bin/mything test -f console
When I run my tests with jest and some of them fails for each item failed I get a list like this:
FAIL src/app/models/item.model.spec.ts
● Item› #getItem › do stuff
expect(received).toBeFalsy()
Received: true
293 |
294 | test('do stuff', () => {
> 295 | expect(true).toBeFalsy();
| ^
296 | });
297 | });
298 | });
at src/app/models/item.model.spec.ts:295:20
at ZoneDelegate.Object.<anonymous>.ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:391:26)
at ProxyZoneSpec.Object.<anonymous>.ProxyZoneSpec.onInvoke (node_modules/zone.js/dist/proxy.js:129:39)
at ZoneDelegate.Object.<anonymous>.ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:390:52)
at Zone.Object.<anonymous>.Zone.run (node_modules/zone.js/dist/zone.js:150:43)
at Object.testBody.length (node_modules/jest-preset-angular/zone-patch/index.js:52:27)
which is the same info that I get above when the test first failed. In the case when a suite is really big and something breaks all their tests (or in more than one file) is really impossible to read that list because the details are always between the FAIL title and test names.
Is there a way to do jest to print a compact Failed Tests summary like this?
FAIL src/app/models/item.model.spec.ts
● Item› #getItem › do stuff
● Item› #getItem › do another Stuff
FAIL src/app/models/loader.model.spec.ts
● Loader> #loadSomething › be cool
● Loader› #loadAnything › be cooler
So if I want to read the fail details I can just scroll up or filter the failed test in my next run.
I am facing an issue with the execution of following Groovy Script snippet.
GroovyShell sh = new GroovyShell();
sh.evaluate("\"abcd\".length() >= .34");
I am getting the following exceptions. The entire stack trace is mentioned below.
Exception in thread "main" org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: 1: unexpected token: >= # line 1, column 17.
"abcd".length() >= .34d
If I change .34 to 0.34, it works. However, because of some limitation, I won't be able to change the script content.
Any help to overcome will be appreciated.
I am getting the following exceptions
Exception in thread "main" org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: 1: unexpected token: >= # line 1, column 17.
"abcd".length() >= .34d
^
1 error
at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:150)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:120)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:132)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:350)
at org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:144)
at org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:110)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:234)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:168)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:943)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:605)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:584)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594)
at groovytest.Testtest.main(Testtest.java:18)
Your Groovy snippet is incorrect - Groovy does not support notation without leading zero in case of decimal numbers smaller than 1.0. If you try to compile following expression directly using groovyc:
"abcd".length() >= .34
compilation will fail with error like:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
test.groovy: 2: Unexpected input: '.' # line 2, column 20.
"abcd".length() >= .34
^
1 error
Java supports such notation, however Groovy from 2.x up to 3.0.0-alpha-3 version does not support it.
Solid solution
Fix the input Groovy code snippet to contain only a valid and compile-ready code. Any invalid Groovy statements or expressions will lead to failures and compilation errors.
Workaround: add leading zeros with replaceAll() method
The only way to compile such incorrect snippet is to replace all .\d+ (dots followed by at least one space and ended with a number) with 0.$1. Consider following example:
def snippet = "\"abcd\".length() >= .34; \"efgh\".length() >= .22; \"xyz\".length() >= 0.11;"
println snippet.replaceAll(' \\.(\\d+)', ' 0.$1')
It adds 0 to all decimal numbers where leading zero is missing. Running this example prints following output to the console:
"abcd".length() >= 0.34; "efgh".length() >= 0.22; "xyz".length() >= 0.11;
If you pass such modified snippet to GroovyShell.evaluate() method it will run with no errors.
Of course this is not a rock-solid solution and it is just a way to automatically fix some of the syntax errors introduced in the code snippet. There are some corner cases where this workaround may cause some side effects, you have to be aware of it.