I'm new to Rust, I have a file structure like this
main.rs
chip8.rs
chip8_gui.rs
I added a unit test in main.rs and a unit test in chip8.rs (a simple assert_eq!(2,2)) but it only finds the test in main.rs. Why? I am trying to test a private function of chip8.rs.
Turns out TDD is fun, but you have to make sure it compiles! The solution was simply to add mod chip8 in main.rs
Related
I would like to implement multiple tests layers.
My project do a lot of stuff and tests are very long.
I would like to have quick tests implemented in CI.
For this purpose I just do a
#[test]
fn deploy_kubernetes_things_and_co(){
...
}
In case of validation of those tests, I run a cargo test test --color always -- --ignored
it runs all my "long tests"
#[test]
fn one_of_my_very_long_integration_test(){
...
}
but I would like to have a third layer of tests, maybe on the night...
How Can I manage to implement it ?
I already read the rust/cargo documentation, I don't see anything else.
Maybe I should create a lib tests called every nights ?
I am using scalatest maven plugin and I would like to run integration test separately from unit tests. The tests path are src/it and src/test for integration test and unit test respectively.
Which is the best approach to achieve this goal?
Thanks
One option is to create an object and then use it as a tag in each test:
object IntegrationTag extends Tag("Integration-Test")
test("Test for correct number of records", IntegrationTag) {
// some stuff
}
Then, if you want to test the Unit Tests simply run the command:
mvn test -DtagsToExclude=Integration-Test
This is a possible solution...sure that will be more.
The built-in unit testing functionality (unittest {...} code blocks) seems to only be activated when running.
How can I activate unit tests in a library with no main function?
This is somewhat related to this SO question, although the accepted answer there deals with a workaround via the main function.
As an example, I would expect unit testing to fail on a file containing only this code:
int foo(int i) { return i + 1; }
unittest {
assert(foo(1) == 1); // should fail
}
You'll notice I don't have module declared at the top. I'm not sure if that matters for this specific question, but in reality I would have a module statement at the top.
How can I activate unit tests in a library with no main function?
You can use DMD's -main switch, or rdmd's --main switch, to add an empty main function to the set of compiled source files. This allows creating a unit test binary for your library.
If you use Dub, dub test will do something like the above automatically.
I am developing one Windows phone 7 application. It has another project for unit testing. Now in the main application I have one method that executes some code to navigate to another page. While unit testing I don't want that method to execute and just return in the first line. Right now how I am doing it is defining a symbol while unit testing.
#define EnableUnitTest
public static void Navigate(string page)
{
#if EnableUnitTest
return;
#endif
.....
.....
}
Is there a better way of doing it.
Sorry to say it but that seems like a very bad design. In a unit test you are testing some code which shouldn't be conditioned that way. A unit test should consist of three steps: Arrange, Act, Assert where you prepare the input, call the actual method and assert the results. It's in the arrange step that you should prepare the method under test.
Also I notice that this method is static. Static methods are difficult to unit test. It would be better to abstract the logic of this class into an interface or abstract base class which could be easily mocked/stubbed in a unit test to weaken the coupling between the different parts of your code.
I am trying to add my first unit test to an existing Open Source project. Specifically, I added a new class, called audio_manager:
src/audio/audio_manager.h
src/audio/audio_manager.cc
I created a src/test directory structure that mirrors the structure of the implementation files, and wrote my googletest unit tests:
src/test/audio/audio_manager.cc
Now, I am trying to set up my Makefile.am to compile and run the unit test:
src/test/audio/Makefile.am
I copied Makefile.am from:
src/audio/Makefile.am
Does anyone have a simple recipe for me, or is it to the cryptic automake documentation for me? :)
If the existing project already has a test structure in place, then you should just add:
TESTS += audio_manager
to the existing tests/Makefile.am. If the existing project does not have a test structure in place, you should run screaming for the hills.
If running for the hills is not acceptable, there's a fair bit of work in getting the test structure in place, but it's not insurmountable. You might prefer to make tests a sibling of src, but that's not necessary. It's probably easier to start with a fresh Makefile.am rather than copying the Makefile.am from src, but maybe not. Possibly, all you'll need to do is change lines of the form:
bin_PROGRAMS = ...
to
check_PROGRAMS = ...
add the line
TESTS = test-audio-manager
change the name of audio_manager.cc to test-audio-manager.cc (that's not strictly necessary, but will help maintainability. I changed _ to - purely out of personal preference) and add a
SUBDIRS = tests/audio
to src/Makefile.am. (If there's already a SUBDIRS directive, append to that assignment or use +=)
William's answer got me where I needed to go. Just for the sake of the community, here's what I ended up doing:
I moved my tests back into the main directory structure and prepended test_, as per William's suggestions.
I added a few lines to src/audio/Makefile.am to enable unit tests:
# Unit tests
noinst_PROGRAMS = test_audio_manager
test_audio_manager_SOURCES = $(libadonthell_audio_la_SOURCES) test_audio_manager.cc
test_audio_manager_CXXFLAGS = $(libadonthell_audio_la_CXXFLAGS)
test_audio_manager_LDADD = $(libadonthell_audio_la_LIBADD) -lgtest
TESTS = test_audio_manager
Now, running "make check" fires the unit tests!
All of this can be seen here: http://github.com/ksterker/adonthell/commit/aacdb0fe22f59e61ef0f5986827af180c56ae9f3
Complimenting the information in the other answers, you can also specify multiple tests to TESTS.
Regardless of how many tests you specify, you don't actually have to specify them twice, instead just set TESTS to $(check_PROGRAMS) - this can help to prevent an accidental situation of adding your test to check_PROGRAMS but forgetting to add it to TESTS, causing your new test to be added to the build, but never being run by make check:
# Unit tests
check_PROGRAMS = test_audio_manager
test_audio_manager_SOURCES = test_audio_manager.cc
TESTS = $(check_PROGRAMS)
...or to do the same with multiple tests:
# Unit tests
check_PROGRAMS = test_audio_manager test_video_manager
test_audio_manager_SOURCES = test_audio_manager.cc
test_video_manager_SOURCES = test_video_manager.cc
TESTS = $(check_PROGRAMS)