I really love cargo and how easy it is to write unit tests.
However, it seems like it's testing functionality is fairly basic. What I'd like to be able to do is have named groups of tests somehow. What I am trying to accomplish is to have a default set of tests that execute when you run the basic cargo test. However, some of my tests take much longer to run, so I'd like to be able to move these to another group of extended tests that I can run with some command like cargo test --extended, and also the ability to be able to run all the tests at once easily. I also have a third group of tests that I have currently implemented as ignored tests so I can run them separately.
Even though all my tests are effectively unit tests, I tried to accomplish this by creating a tests directory as you would do with integration tests. However it seems that the basic cargo test command wants to run the all these tests, i.e. the normal tests that are part of my crate as well as the extended tests in the tests crate.
Does anyone know how to accomplish this or whether there is some crate that provides this functionality?
You could use a combination of feature flags and the #ignore macro as mentioned here: https://www.reddit.com/r/rust/comments/3i1nki/how_to_skip_expensive_tests_with_cargo_test/
Related
I am using Vitest as my testing framework in a project.
I have multiple test files in the project, let's say A.spec.ts and B.spec.test. I am using the standard test script (vitest run --no-threads --coverage) to test my code. I want to run a certain function (to purge and clean the testing database), before and after all the test suites are run (i.e. before all the tests in A.spec.ts and B.spec.ts, and after them as well).
Is there any way to achieve the same? I read about the methods like beforeAll and afterAll, but they work in the context of a file, and thus do not help with my use case.
you should try global setup
globalsetup
I want to code a crate for a REST API. cargo test needs a server where the features can be tested, so I need something like adding "parameters" to the tests.
I looked at the documentation of cargo test to see if I can add command line options like cargo test -- --api-server=https://localhost:80 but it doesn't seem to exist.
One thing that I really like about behave ( https://behave.readthedocs.io/en/stable/ ) is that you can use the stage flag and it will run different step implementations for each one. If you pass the flag --stage=ui, then all step implementations inside ui_steps will run.
I don't want to be stuck with behave, but I didn't see this feature in other runner ( like cucumber.js or even cucumber for java)
Any ideia on how to implement this?
I believe this is possible in cucumberjs. You can pass the location of step deps for cucumber runner. If you have step definitions in separate folders for api and ui tests, you can change your configuration accordingly in your npm script or configuration of the automation tool being used.
You can have two sets of support code and specify which to use via the CLI with --require. Like many things this is easier to manage using profiles.
Aslak (the creator of Cucumber) has a good talk where he is doing something similar to this, using different support code against the same features and steps to test different parts of the stack:
https://www.youtube.com/watch?v=sUclXYMDI94
I have a test suite and because it contains some expensive tests, I disable some of them for our CI. However once a day, I'd like to run the whole test suite.
The issue is that running against the same set of test files, it causes snapshot failures because when running the whole test suite it is missing some. If I generate them, then the CI fails because it complains about snapshots being removed (i.e. the one from the whole test suite that are not being checked on the CI.)
What would be the proper way to handle this with jest?
Thanks!
Are there any extensions to HUnit or QuickCheck that allow a continuous integration system like Bamboo to do detailed reporting of test results?
So far, my best idea is to simply trigger the tests as part of a build script, and rely on the tests to fail with a non-zero exit code. This is effective for getting attention when a test fails, but confuses build failures with test failures and requires wading through console output to determine the problem's source.
If this is the best option with current tools, my thought is to write a reporting module for HUnit that would produce output in the JUnit XML format, then point the CI tool at it as though it were reporting on a Java project. This seems somewhat hackish, though, so I'd appreciate your thoughts both on existing options and directions for new development.
The test-framework package provides tools for integrating tests using different testing paradigms, including HUnit and QuickCheck, and its console test runner can be passed a flag that makes it produce JUnit-compatible XML. We use it with Jenkins for continuous integration.
Invocation example:
$ ./test --jxml=test-results.xml
I've just released a package which generates test-suites based off modules containing quickCheck properties: http://hackage.haskell.org/package/tasty-integrate
This is one step above test-framework/tasty at the moment, as it forcefully pulls/aggregates them off the filesystem, instead of relying upon per-file record keeping. I hope this helps your CI process.