I am using kitchen to run inspec tests for the puppet repository. I am able to apply the entire puppet catalogue ina vagrant box and then run tests for it. But what if I want to run a specific module in the puppet code base alone? I don't want to apply the entire catalogue every single time.
Can kitchen apply specific modules instead of the entire catalogue? And then test for those modules as well?
Something like how in rspec I can specify a test case I want to run.
kitchen converge --path-to-file
kitchen verify --path-to-test-file
Related
I am having an issue while trying to set up a Github action that runs my Jest test suite. It fails due to using snapshots. It appears the issue might be caused by the colored formatting on the error messages.
Screenshot provided because I couldn't get the color formatting to copy over to this question using only markdown.
The tests all pass locally, so I know the logic works. It is an issue in the Github test runner, but I'm not sure how to address it. If I remove those particular tests, it will drop my code coverage. How do I get the tests to pass in this environment?
Assuming you run your tests with npm test, you can set the environment variable FORCE_COLOR and thereby make jest use color in GitHub Actions as well:
- run: npm test
env:
FORCE_COLOR: true
Scenario
I'm working on an app that has fast unit/functional jest tests along with slower end-to-end jest-puppeteer tests. I would like to split those up so that I can run the faster tests as part of a git pre-commit hook and leave the end-to-end tests to be run on CI after the code is eventually pushed to origin.
Question
How can I define specific tests to run at pre-commit? Specifically via regex similar to jest moduleNameMapper eg <rootDir>/__tests__/[a-z]+\.unit\.test\.js
Best idea so far:
in package.json add test:pre which uses bash find . -regex with bash for do to run desired "pre commit" tests
I've added
"test:pre": "PRE=1 npm test -- test/pre-*test.js"
# everything after -- is a kind of regex filter for matching file names
to my package.json scripts and in my jest-puppeteer global-setup.js I'm using
if(+process.env.PRE) return;
before all the puppeteer extras are started. So now I can
$ npm run test:pre
and violá
I want to add unit testing for my ansible playbook. I am new to this and have tried few things but didn't understood much. How can I start on this and write a test case properly?
Following is the simple example:
yum:
name: httpd
state: present
Ansible is not a programming language but a tool that will check the state you describe is aligned with the state of the node your run in against. So you cannot unit tests your tasks. They are in a certain way tests by themselves already. The underlying ansible binary that runs those task has unit tests itself used during its development.
Your example above is asking ansible to test if httpd is present on the target machine and will return ok if this is the case, changed if it had to install the package to fulfill the requirement, or error if something went wrong.
Meanwhile, it is not because you cannot unit test your ansible code that no tests are possible at all. You can perform basic static checks with yammlint and ansible-lint. To go further, you will have to run your playbook/role/collection against a test target node.
This has become quite easy with CI that will let you spawn virtual machines or docker container from scratch and run your script to test that no error is fired, the --check option passes successfully, idempotency is obeyed (i.e. nothing should change on a second run with the same parameters), and everything works as expected (e.g. in your above case port 80 is opened and your get the default Apache web page).
You can write those kind of tests yourself (running against localhost in a test vm for example). This Mac Appstore CLI role by Geerlinguy is using such tests through travis-ci as an example.
You can also use existing tools to help you write those tests in a more structured way like molecule. Here are some example roles using it if you are interested:
Redis role by Geerlinguy
nexus3-oss role by ThoTeam [1]
[1] Note for transparency: I am the maintainer of this example repository
I having hard time figuring out how to run the unit tests of a sawtooth hyperledger transaction processor. I am following their documentation on this topic:
https://sawtooth.hyperledger.org/docs/core/releases/1.0/app_developers_guide/testing.html
However, it does not explain the modus operandi of setting up the necessary environment, etc and actually running the unit tests. I have tried building the docker compose file which seemingly tries to build and run tests:
docker-compose -f sawtooth-core/sdk/examples/xo_python/tests/test_tp_xo_python.yaml up
The docker-compose file seems to contain some environment vars such as
$SAWTOOTH_CORE
$INSTALL_TYPE
$ISOLATION_ID
Not sure what value needs to be set to the above environment variables and in my case it fails because it fails to get the values for these vars..
Any thoughts, pointers or direction on how to run the tests for the processor would be very helpful.
Many thanks!.
You can poke around the Sawtooth core repo and find the values:
https://github.com/hyperledger/sawtooth-core
SAWTOOTH_CORE is the root directory of where you cloned the sawtooth-core git repository (default is your current directory)
INSTALL_TYPE is local (there may be other values, but I do not know them)
ISOLATION_ID is the Sawtooth Version. For example, 1.1 . It is used to identify the Docker container to download.
You can run the tests through Docker with
bin/run_tests
Sawtooth testing is currently done with Jenkins CI. Start at Jenkinsfile to see how testing is done.
I'm using Codeship for continuous deployment. My app is setup so that the main app loads a few engines, and the engines isolate specific functionality. Each engine might have various rspec tests related to it's isolated functionality. Codeship spins up a copy of my app, runs a few commands, and deploys the code if everything works. Those few commands need to run all my tests. bundle exec rake or bundle exec rspec no longer work, as they only run the tests on my main container app (none of the engines).
I ended up created the following shell script that loops through the directories inside my gems directory, and calls bundle install and bundle exec rspec:
retval=0
for dir in gems/*/
do
dir=${dir%*/}
echo "## ${dir##*/} Tests"
cd gems/${dir##*/}
bundle install
if ! bundle exec rspec spec/ --format documentation --fail-fast;
then
retval=1
break
fi
cd ../../
done
exit $retval
This works well. All my tests are executed, and it exits with an error if any tests fail. In an effort to see if there was a better way to accomplish this, I tried moving this functionality into a rake tasks. I attempted a couple methods. I used the FileUtility methods to loop through the directories and the System method to call the same bundle install and bundlee exec rspec as above. The commands are called, but when it is ran from the rake tasks, their is a problem with the factories. If Engine A calls factories from Engine B, the returned values are nil. I'm calling shared factories this way (example from Engine A):
FactoryGirl.define do
factory :Model, class: EngineB::Model do
end
end
Sorry this is long winded. To sum up my questions:
1) Is the shell script a good way to manage tests? I haven't ran into any issues with it yet.
2) Do you know why calling that shell script from a rake task causes the factories to return nil values?
3) Do you know why mimicking the shell functionality in a rake tasks also results in the factories returning nil values? (probably same problem as above)
4) Is there a better way to share factories? I've placed all models that are referenced in multiple engines in one engine.