I have the following Ginkgo test file:
package foo
import (
"log"
. "github.com/onsi/ginkgo"
)
var _ = BeforeSuite(func() {
log.Print("BeforeSuite")
})
var _ = AfterSuite(func() {
log.Print("AfterSuite")
})
var _ = Describe("Foo", func() {
log.Print("Describe")
})
When I run ginkgo -r -v, the test file runs, but the BeforeSuite and AfterSuite do not appear to:
2016/03/16 09:23:17 Describe
testing: warning: no tests to run
PASS
The line 2016/03/16 09:23:17 Describe shows that the Describe is running, but where is the output for BeforeSuite and AfterSuite?
I do not really care about the output, but in my real test (not the fragment above), database build up and tear down are not getting executed.
What am I doing wrong?
You are not invoking RunSpecs
func TestSo(t *testing.T) {
RunSpecs(t, "My Test Suite")
}
Output then appears similar to
2016/03/16 07:16:05 Describe
Running Suite: So Suite
=======================
Random Seed: 1458137764
Will run 0 of 0 specs
2016/03/16 07:16:05 BeforeSuite
2016/03/16 07:16:05 AfterSuite
Ran 0 of 0 Specs in 0.000 seconds
SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 0 Skipped PASS
Ginkgo ran 1 suite in 1.211144437s
Test Suite Passed
Are you trying to run your actual tests in the _suite_test.go file?
Related
I need to include some generated files (for example output from go-swagger) in a binary. Without bazel you can do that using go:generate in combination with go:embed:
package demo
//go:generate swagger generate spec -w . -o ./openapi.json
import "embed"
// Content contains openapi.json file generated via go-swagger from spec
//go:embed openapi.json
var Content embed.FS
I am trying to do the same thing with bazel. As a simple test I have have this BUILD.bazel file:
genrule(
name = "hellodata",
srcs = ["hello.go"],
outs = ["hello.txt"],
cmd = "cat $(SRCS) | tr A-Za-z N-ZA-Mn-za-m > $#",
)
go_library(
name = "hello",
srcs = ["hello.go"],
importpath = "wiggy.net/hello",
visibility = ["//visibility:public"],
embedsrcs = [":hellodata"],
)
with hello.go looking like this:
package hello
import (
_ "embed"
"io"
)
//go:embed hello.txt
var greeting []byte
func Hello(out io.Writer) error {
_, err := out.Write(greeting)
return err
}
The intention here is to have Hello output the rot13 of it's own source. When I try to compile this it successfully generates hello.txt (located in bazel-out/darwin_arm64-fastbuild/bin/hello.txt), but the compiler can not find it:
❯ bazel build //...
INFO: Analyzed 5 targets (0 packages loaded, 0 targets configured).
INFO: Found 5 targets...
ERROR: /Users/wichert/Hack/bzl/BUILD.bazel:14:11: GoCompilePkg hello.a failed: (Exit 1): builder failed: error executing command bazel-out/host/bin/external/go_sdk/builder compilepkg -sdk external/go_sdk -installsuffix darwin_arm64 -src hello.go -embedsrc bazel-out/darwin_arm64-fastbuild/bin/hello.txt -importpath wiggy.net/hello ... (remaining 12 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
compilepkg: /private/var/tmp/_bazel_wichert/e7573342ee9452df4c3dfa671d399a16/sandbox/darwin-sandbox/76/execroot/__main__/hello.go:8:12: could not embed hello.txt: no matching files found
INFO: Elapsed time: 0,112s, Critical Path: 0,04s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
I noticed -embedsrc bazel-out/darwin_arm64-fastbuild/bin/hello.txt in the command line for the failing action in your question, so as a hunch I tried the equivalent on my machine:
//go:embed bazel-out/k8-fastbuild/bin/hello.txt
var greeting []byte
And that seemed to work.
This is not so great because configuration information gets embedded in the source files (indeed, on your mac machine it's darwin_arm64-fastbuild and on my linux machine it's k8-fastbuild), so now your source code is artificially platform dependent.
It looks like this feature is relatively new (https://github.com/bazelbuild/rules_go/issues/2775, https://github.com/bazelbuild/rules_go/issues/2986). I would file an issue with rules_go about this.
There also appears to be go_embed_data which might behave differently:
https://github.com/bazelbuild/rules_go/blob/master/docs/go/extras/extras.md#go_embed_data
To answer my own question: the trick is to use genrule to generate the file(s) to be embedded, and then use go_embed_data to embed them. A work BUILD.bazel looks like this:
genrule(
name = "hellodata",
srcs = ["hello.go"],
outs = ["hello.txt"],
cmd = "cat $(SRCS) | tr A-Za-z N-ZA-Mn-za-m > $#",
)
go_embed_data(
name = "hello_embed",
src = ":hellodata",
package = "hello",
var = "greeting",
)
go_library(
name = "hello",
srcs = [
"hello.go",
":hello_embed",
],
importpath = "wiggy.net/hello",
visibility = ["//visibility:public"],
)
Facing problem in a question:
Write a gradle program to generate 10 fibonaci series, with task name as fibo, and variable name as num. Use command line argument for num.
For example, if a task name is test and I want to pass 10 as the input, use gradle test -Pnum=10.
I have created a function:
def fibo(n){
a = 0
b = 1
if (n == 1)
println a
else if
(n == 2)
println a + " " + b
else if (n > 2) {
print a + " " + b
i = 2
while (i <= n)
{
c = a + b
print " " + c
a = b
b = c
i = i + 1
}
}
}
My question is, how to link it with a task as I encounter error like:
FAILURE: Build failed with an exception.
* What went wrong:
Task 'fibo' not found in root project 'root'.
* Try:
Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 2.61 secs
or how to pass parameters in a gradle task?
Note: Please do not suggest optimization in fibonacci code, thats not a concern for now.
You can define a task like this:
def hello(name) {
println "Hello, $name"
}
task sayHello() {
doLast {
hello sayHelloTo
}
}
And call it like this:
% gradle sayHello -PsayHelloTo=World
> Task :sayHello
Hello, World
BUILD SUCCESSFUL in 518ms
1 actionable task: 1 executed
def fibo(num) {
if (num < 2) {
return 1
} else {
return fibo(num-2) + fib(num-1)
}
}
task (fibo) << {
println fibo(5)
}
I have a FAKE script that is attempting to run MSTest.
I am getting a 'Not Defined' error on MSTest.
From what I can gather in the documentation the MSTest helper should be in FakeLib.dll and in the 'Fake' namespace. Is that wrong?
Why would I be getting this error?
#I "packages/FAKE/tools"
#r "packages/FAKE/tools/FakeLib.dll"
open Fake
... many build steps working fine
Target "UnitTest" (fun _ ->
trace "Run Unit Tests..."
!! (testDir ## "*.Tests.dll")
|> MSTest (fun p -> { p })
()
)
I had to include the open Fake.MSTest. Below is the snippet I use for unit tests.
open Fake.MSTest
Target "UnitTests" (fun _ ->
let msTestParams p =
{ p with
ResultsDir = resultsDir
WorkingDir = testOutDir
TestSettingsPath = sd ## "Local.testsettings"
ErrorLevel = ErrorLevel.Error
NoIsolation = false }
!! (testOutDir + #"\*.Tests.dll")
|> MSTest msTestParams
)
Observable.of("A", "B", "C").subscribe{ print("test", $0) } // run 4 times
--- output:
test next(A) test next(B) test next(C) test completed
but the code: why run only 1 times
Observable.of("A", "B", "C").subscribe{ print("test") }
--- output
test
I am writing a new crate. I wrote some tests for it and run the tests using cargo test. After that, some test_xxx executables are generated in the target folder. I have enabled the debug option in Cargo.toml. By running gdb targets/test_xxx, I can list and debug the code in the test_xxx executable. However, I could not step into the functions in the crate. There is no debug information. How can I build/link the crate to include its debug information?
Your question is a bit fuzzy, so I'll describe what I did:
Create a new crate:
cargo new --lib so
cd so/
Add a small bit of code:
src/lib.rs
fn thing1(a: i32) -> i32 {
a + 2
}
fn thing2(a: i32) -> i32 {
a * a
}
pub fn do_a_thing(a: i32, b: i32) -> i32 {
thing2(b) - thing1(a)
}
Created an external test; one that lives in tests. This matches your comment about test_XXX, as best I can guess:
tests/alpha.rs
#[test]
fn it_works() {
assert_eq!(1, so::do_a_thing(1, 2))
}
Run the tests (output trimmed):
% cargo test
Running target/debug/deps/alpha-b839f50a40d747a9
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Open it up in my debugger:
% lldb target/debug/alpha-b839f50a40d747a9
Set a regular expression breakpoint on a method in the crate and run it:
(lldb) br set -r 'do_a_thing'
Breakpoint 1: where = alpha-b839f50a40d747a9`so::do_a_thing::hd55d34fb5a87e372 + 14 at lib.rs:10:11, address = 0x0000000100001f9e
(lldb) r
Process 53895 launched: '/tmp/so/target/debug/alpha-b839f50a40d747a9' (x86_64)
running 1 test
Process 53895 stopped
* thread #2, name = 'it_works', stop reason = breakpoint 1.1
frame #0: 0x0000000100001f9e alpha-b839f50a40d747a9`so::do_a_thing::hd55d34fb5a87e372(a=1, b=2) at lib.rs:10:11
7 }
8
9 pub fn do_a_thing(a: i32, b: i32) -> i32 {
-> 10 thing2(b) - thing1(a)
11 }
Target 0: (alpha-b839f50a40d747a9) stopped.
(lldb) p b
(int) $0 = 2
(lldb) p a
(int) $1 = 1
(lldb) br set -r 'thing2'
Breakpoint 2: where = alpha-b839f50a40d747a9`so::thing2::hf3cb71248518a556 + 11 at lib.rs:6:4, address = 0x0000000100001f5b
(lldb) c
Process 53895 resuming
Process 53895 stopped
* thread #2, name = 'it_works', stop reason = breakpoint 2.1
frame #0: 0x0000000100001f5b alpha-b839f50a40d747a9`so::thing2::hf3cb71248518a556(a=2) at lib.rs:6:4
3 }
4
5 fn thing2(a: i32) -> i32 {
-> 6 a * a
7 }
8
9 pub fn do_a_thing(a: i32, b: i32) -> i32 {
Target 0: (alpha-b839f50a40d747a9) stopped.
(lldb) p a
(int) $2 = 2
This indicates that I was able to set breakpoints and debug in my crate.
For dependent crates
I added this to my Cargo.toml:
[dependencies]
time = "0.1.0"
Along with this code:
src/lib.rs
pub fn do_another_thing() -> bool {
time::precise_time_ns() % 2 == 0
}
And this test (still in the external test file):
tests/alpha.rs
#[test]
fn it_works2() {
assert_eq!(true, so::do_another_thing())
}
Built and ran the tests as before, then opened it in the debugger as before:
(lldb) br set -r 'precise_time'
Breakpoint 1: where = alpha-25aace4e290c57ee`time::precise_time_ns::h21114d10b3e2c8e8 + 8 at lib.rs:161:4, address = 0x0000000100002278
(lldb) r
Process 54043 launched: '/tmp/so/target/debug/alpha-25aace4e290c57ee' (x86_64)
running 2 tests
test it_works ... Process 54043 stopped
* thread #2, name = 'it_works2', stop reason = breakpoint 1.1
frame #0: 0x0000000100002278 alpha-25aace4e290c57ee`time::precise_time_ns::h21114d10b3e2c8e8 at lib.rs:161:4
158 */
159 #[inline]
160 pub fn precise_time_ns() -> u64 {
-> 161 sys::get_precise_ns()
162 }
163
164
Why a regex breakpoint?
Function names are mangled and namespaced. Our functions are actually called so::do_a_thing::hd55d34fb5a87e372 or time::precise_time_ns::h21114d10b3e2c8e8. Using a regex breakpoint selects those easily without thinking about the exact name.
You can also use LLDB's autocompletion
(lldb) b so::<TAB>
Available completions:
so::do_a_thing::hfb57d28ba1650245
so::do_another_thing::hace29914503d7a2f
so::thing1::ha6f7818d54de28d4
so::thing2::h2518577906df58fd
(lldb) b time::<TAB>
Available completions:
time::precise_time_ns::h21114d10b3e2c8e8
time::sys::inner::mac::get_precise_ns::h64c88ed88da4ac18
time::sys::inner::mac::info::_$u7b$$u7b$closure$u7d$$u7d$::ha03be28d018f231b
time::sys::inner::mac::info::h364c1a0ef2ef1f0c
Using GDB instead of LLDB
You can also use GDB, but it looks like it may be a bit harder. After setting a breakpoint in the primary crate's code, I stepped in and saw the function name seem to be the mangled version. You can use that as a breakpoint though.
Note my regex breakpoint doesn't work as intended, and also note the line number of the real breakpoint:
(gdb) rbreak precise_time_ns
u64 _ZN4time15precise_time_nsE()();
static u64 _ZN4time15precise_time_ns18os_precise_time_nsE()();
Breakpoint 1 ('_ZN4time15precise_time_ns18os_precise_time_ns13closure.24322E') pending.
<function, no debug info> time::precise_time_ns::os_precise_time_ns::closure.24322;
(gdb) b _ZN4time15precise_time_nsE
Breakpoint 2 at 0x1000052a0: file lib.rs, line 172.
(gdb) r
Starting program: /private/tmp/so/target/alpha-e0c6f11f426d14d2
running 2 tests
test it_works ... ok
[Switching to process 49131 thread 0xd03]
Breakpoint 1, _ZN4time15precise_time_nsE () at lib.rs:172
172 pub fn precise_time_ns() -> u64 {
(gdb) list
167
168 /**
169 * Returns the current value of a high-resolution performance counter
170 * in nanoseconds since an unspecified epoch.
171 */
172 pub fn precise_time_ns() -> u64 {
173 return os_precise_time_ns();
174
175 #[cfg(windows)]
176 fn os_precise_time_ns() -> u64 {
Debugger wrappers
There are two wrapper programs shipped with Rust: rust-lldb and rust-gdb. These are intended to increase the usefulness of each debugger. It's worth giving them a shot.
After receiving an answer, I found that this doesn't happen to all methods in an external crate, but only generic ones. I filed issue 19228 with the detailed steps.
This is what I am doing to debug the generic methods in the meantime:
Write the tests in the tests folder as usual. Run "cargo test" to check if it is successful.
If it fails, I move the test code into the crate lib.rs file and build a binary using "rustc -g src/lib.rs".
Use gdb to debug lib.