It doesn't seem like Jest allows all the test runs to share a global context for integration testing. It does have globalSetup and globalTeardown options, but it doesn't seem like those hooks are intended to be a shared testing context across all test runs. You can hack something together using these hooks, passing variables through the node process, but then other issues start to arise (Different instances of Array constructors during assertions, etc...).
If I have a fairly heavy integration test setup process, is it recommended that I only have one test run, where all my integration tests would live and have access to the shared context?
Currently my integration tests are spread across multiple files (individual entry points) and import a setup process. However that setup process is getting run once per file. I'm assuming that alternatively I can have one entry point and then import all my integration test files within the same context. Is that a good/recommended option?
What's the recommended way of setting up integration tests for use in Jest?
I've solved this issue using a combination of 2 solutions:
Jest setupTestFrameworkScriptFile: https://jestjs.io/docs/en/23.x/configuration#setuptestframeworkscriptfile-string
NodeJS Global objects: https://stackabuse.com/using-global-variables-in-node-js/
Using the jest one time setup I can execute my setup only once, and store the results as variables in the NodeJS global object.
Example:
// package.json
"jest": {
"setupTestFrameworkScriptFile": "<rootDir>/globalSetupFile.js"
}
// globalSetupFile.js
global.globalUser = createGlobalUser();
// testFile.spec.js
loginAsUser(global.globalUser.email, global.globalUser.password);
Related
I am trying to set up my Xamarin.Forms application to use UI Tests. Currently the tests are working fine, but I would like to be able to mock or handle the API calls that the application calls, rather than the actual API calls being executed in the tests.
There appears to be a way that UITest can detect if it is running in Test Cloud, but I can't seem to find a way for the application to know if it is running tests locally. I am using an IoC Container to register the various interfaces that interact with these APIs, and would like the App constructor to be able to detect if it is running a UITest, then register the appropriate 'actual' interface instances or the 'mock' instances. Is there a known way to handle this?
Your issue can be solved in many ways, but this is what I actually do:
You can create a dedicated compiler configuration:
Then, based on the configuration you would manipulate your container boostrap pointing your interfaces to the mock objects.
Whenever you want to run UI tests you would compile this configuration instead of the release configuration.
I am using Google Firebase Cloud Functions with TypeScript, and I found out that even though each function is deployed separately, they all share the same bundles and dependencies, even if some functions do not use them nor import them.
In my case, one cloud function uses Redis and others don't. I have 10 functions. All 10 functions actually end up importing redis related code even though they don't import them.
Since all functions share the same entry point, index.js. It currently seems it's impossible to have separate tree-shaken bundles / entry points for each function.
This is very inefficient in terms of bundle size / cold start timing / memory / etc. It also means as I have more and more functions, bundle size will grow for all functions together. It's not scalable.
Is there any way to not share the entry point, index.js, and have completely separate bundles by using bundlers like webpack?
You can create a different local Firebase working area (with firebase init) for each function that should deploy in isolation from the others. You will have to instruct the CLI not to overwrite the other functions on deployment using the --only functions:yourFunctionName to deploy it.
Or, you can deploy function using Cloud tools (gcloud) instead of Firebase tools, but you won't be able to use firebase-functions and its TypeScript bindings.
Or, you can lazily load your modules instead of statically loading them at the global scope of your functions, as described in this video.
I don't recommend using webpack. It's not going to be worth your time to get it configured.
You might try better-firebase-functions, which solves this elegantly by automatically lazy loading only the function that is currently invoked by checking the environment variable FUNCTION_NAME - see https://link.medium.com/4g3CJOLXidb
I was wondering if it was possible to access the settings defined within my karma.config.js file, and if so how?
I'm currently using a Grunt task runner to perform various tasks like building, linting, packaging, etc. I'm also using Grunt to kick off the Karma test runner to run my Jasmine unit tests. Furthermore, I'm pulling in the Jasmine-jQuery library so I can define and read in JSON and HTML fixtures from separate files that I setup earlier.
While I was writing some new tests, I noticed that I was redefining my fixtures base path in every test file. So I decided to pull it out and put it into a global constant.
The problem I'm having is where I should define it. Currently, I have a file named "testSettings.js" that I'm including in my karma configuration, where I define a configuration object and set it to window.testSettings. Thats all well and good, but I think it would be better if I defined it within my karma configuration and then just referenced that from my tests. But there doesn't look like a way to do this... or is there?
My library versions are:
"karma": "~0.12.32"
"karma-jasmine": "~0.3.5"
"karma-jasmine-jquery": "~0.1.1"
I recently created a Meteor package and want to write some tests. What my test package basically do is that users can insert into the template {{> abc}} and they'll get an HTML element printed on the page.
With TinyTest, all you can do is test the package's API using something like test.equal(actual, expected, message, not). However, I need it to test whether the element was successfully printed on the page. Furthermore, I will pass the template some parameters and test them too.
It seems like I'd have to create a dummy app, run bash to initiate the app, and test whether the elements can be found on page. So should I only use TinyTest to test the API, and write my own tests (somehow!) for templating? If not, how should I go about it?
I read something about Blaze.toHTML, but I cannot find anything in the documentation on it? Nor it's source page.
I think TinyTest is great for starting with Unit testing, but what you need sounds more like an Integration test.
I would recommend you look into the following links for more info on testing with Meteor, especially with Velocity - Meteor's official testing framework:
Announcing Velocity: the official testing framework for Meteor applications
Velocity
The Meteor Testing Manual
You can create a demo application, and run integration tests using Mocha or Jasmine.
I am running test using a phpunit.xml.dist file. This file defines several test suites and specifies a bootstrap.php. In this bootstrap.php I am currently loading all dependencies for all tests.
A small subset of the tests is dependent on some third party library, which is optional. These tests are all part of a particular test suite. So I only want to load this library in the bootstrapping file when that particular test suite is specified.
How can I determine if this test suite was specified? This then ensures that most tests can be run when the library is not loaded, and that one can easily verify the code and tests that should not depend on the library indeed do not need it.
I currently have the following. Is there something better?
if ( !in_array( '--testsuite=WikibaseDatabaseStandalone', $GLOBALS['argv'] ) ) {
require_once( __DIR__ . '/evilMediaWikiBootstrap.php' );
}
The feature request on the PHPUnit bugtracker for a test suite specific bootstrap is here: https://github.com/sebastianbergmann/phpunit/issues/733
For now there are two options: One is yours which is fine but feels really hackish and doesn't work out well if you run "all the tests" if you have specific bootstrap for every one of them.
My suggestion would be to write a test listener and hook into "startTestSuite" and "endTestSuite". This is a nice maintained and BC compatible way to execute code only when the test suite is actually started and you can also clean up afterwards.
See http://phpunit.de/manual/3.7/en/extending-phpunit.html#extending-phpunit.PHPUnit_Framework_TestListener and http://phpunit.de/manual/3.7/en/appendixes.configuration.html#appendixes.configuration.test-listeners for how to include the test listener.
One of the usual way to handle this is to check if a required dependency is installed, and if not, run
$this->markTestAsSkipped('lib not installed');
That skipping can also happen in the setUp() phase of a test.
Finally, you can add #group annotations to the test-class and/or test functions to give some choice to whether or not the test is run from the command line (with the --group [names...] parameter).
Finally, an option that has also been used in the ZendFramework is to only add the TestSuite that runs a subset within a larger set of a testsuite - in code. There is an example of being able to
a) turn off as will,
b) turn off if the extension is not loaded, or
c) run the tests, for the use of (for example)
caching with APC