I want to make continuous integration for my chrome extension.
Using tools: GitHub, Travis, Bower, components-jasmine.
In .travis.yml:
install bower
in bower download jasmine
change default SpecRunner.html on my SpecRunner.html, which contains my src and specs
load my SpecRunner.html in phantomjs
.travis.yml:
language: node_js
node_js:
- "0.10"
install:
- npm install -g bower
- bower install
- cd $TRAVIS_BUILD_DIR
script:
- mv -f ./test/SpecRunner.html ./vendor/components-jasmine
- phantomjs ./test/runTests.js
runTests.js:
var page = require('webpage').create();
page.open('../vendor/components-jasmine/SpecRunner.html', function(){
phantom.exit();
});
Tests should be failed, but status on travis - passed.
Why my tests don't run?
Results of tests is showing on the same SpecRunner.html.
For getting results need to print this loaded page.
If html loaded in phantomjs locally, then url should to follow classic Url/Uri rules, especially for a local file (that's why page not loaded):
file:///c:/path/to/the%20file.txt #win
file:///etc/fstab #unix
For getting results of tests need parse logs in after_script in .travis.yml and return value - 0 if tests passed or non-null if tests failed.
Also, probably, it's possible with help itself jasmine (but i'm not sure).
Try to add after_script: echo $? to .travis.yml to see what is the return value of your test. If it's 0 then Travis behavior is correct.
I merely guess that your test just return 0 regardless of a result. According to the documentation this code just tries to open the file and calls a callback on failure - since there is no not-0-exit callback whole scripts exits normally and build passes.
EDIT:
From what you wrote I understand that Travis runs just fine, and it's phantomjs ./test/runTests.js that isn't returning non 0 value. Try to change:
function(){
phantom.exit();
}
into something like:
function(status){
if (status === 'success')
phantom.exit(0);
else
phantom.exit(-1);
}
And say it that fail the build (I assume that page opening always fails).
Related
I am attempting to run Jest on my project. I am on a Windows 10. I only have one test in one test file.
In package.json:
"test": "jest"
My directory structure:
src/
app/
routeName/
redux/
action.tests.js
My output:
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\Users\myUsername\Documents\myApp
47 files checked.
testMatch: **/__tests__/**/*.[jt]s?(x), **/?(*.)+(spec|test).[tj]s?(x) - 0 matches
testPathIgnorePatterns: \\node_modules\\ - 47 matches
testRegex: - 0 matches
Pattern: - 0 matches
npm ERR! Test failed. See above for more details.
According to the documentation here, Jest should look for anything that has test.js in the name.
I have also tried tests.js and that didn't work either.
I created a folder in the root of the project and put a test in there as __tests__/tests.js and that did work, but I do not want it placed there.
I have seen several tickets and questions about questions that are superficially similar, but all of those involve more complex configurations, or bugs that were supposedly patched already. I have no special configurations set. The documentation says this should work. Tutorials I have read for Jest include the exact setup I am currently using.
I am using Babel and Webpack. I installed the jest and babel-jest packages. I also added jest to the ESLint environment.
[edit] updated to properly document my problem, which I answered below. I lost track of my file naming.
I am a bloody idiot and I didn't pay attention to the details.
Jest is looking for test.js specifically. Not testS.js. My files were labeled as tests.js. It worked inside __tests__/ because Jest just looks for anything inside there.
I got it working just fine now, and it shall remain up as a testament to me not looking at the specifics of the regex matches.
I had the same Problem with a React-App. Make sure, that the jest config file has the correct file pattern to find the tests:
// jest.config.js
module.exports = {
testMatch: [
'<rootDir>/src/**/*.test.js',
'<rootDir>/src/**/*.test.jsx',
],
...
}
From my side, I was getting this error because I had placed myself (cd) in the directory where the chromeDriver was installed, so as not to have to add its path to $Path. After I added chromeDriver to $Path, and placed myself in the directory of my project, everything went fine.
No tests found, exiting with code 1
All I had to do was npm install.
Then I hit the Debug link at the top of my test. The test was found and execution stopped at the breakpoint. A simple solution to a very frustrating problem.
You just need to change the name of the file. For example
if you have a customer.js or customer.ts file and you want to test it. Create a new file name is customer.test.js or
customer.test.ts after npm test it will test the file which just for testing .
I had the same problem, I wanted to run my tests inside drone CI pipeline and had the same error what solved my problem was simply adding workspace to my project.
check if it is small case like filename.test.js.
I made a mistake ComponentName.Test.js and got error, fixed it by ComponetName.test.js
I'm using webpack-dev-server and the Cypress GUI for a development workflow and I'd like for Cypress to automatically re-run/restart tests when the page reloads as triggered by WDS auto-reload.
What happens now is that I see WDS cause the page to reload, but the Cypress session just stays where it left off.
I can't seem to find a way to make this happen. I'm not seeing any public (or private, for that matter) way to trigger Cypress to re-run the currently selected test.
UPDATE: Now there's an NPM package for this
cypress-hmr-restarter - it listens to the websocket that webpack-dev-server uses to reload the page
npm install --save-dev cypress-hmr-restarter
in cypress/support/index.js:
// cypress/support/index.js
import 'cypress-hmr-restarter'
see https://github.com/cypress-io/cypress/issues/456#issuecomment-566499738
Older hacky solution:
You can add the following to cypress/support/index.js (or at the top of a spec file):
Cypress.on('window:before:load', (win)=>{
const _consoleInfo = win.console.info
win.console.info = function () {
if (arguments[0].includes('App updated.')) {
cy.$$('.restart', top.document).click()
}
return _consoleInfo.apply(win.console, arguments)
}
})
This will work as long as you have webpack-dev-server info being printed to the console (there are no other hooks into the webpack reloading behavior I could find)
The $('.restart').click() is a hilariously simple way to trigger a test re-run
Alternatively, you could try this plugin which sets up its own watchers on your source files, and re-runs your tests when changes are detected: https://github.com/bahmutov/cypress-watch-and-reload
#kuceb Thanks for the update regarding cypress-hmr-restarter!
For my Angular 14 project I had to set (in cypress.json):
"hmrUrl": "ws://localhost:4200/ng-cli-ws"
Works like a charm!
I read all the related mocha "describe" is not defined posts but none of them seem to be suitable for my situation.
I use meteor and installed the "mocha": "^3.5.0" package by npm
I have created a /testfolder in my meteor root directory.
and a sample test mochatest.js
var assert = require("assert"); // node.js core module
describe('Array', function(){
describe('#indexOf()', function(){
it('should return -1 when the value is not present', function(){
assert.equal(-1, [1,2,3].indexOf(4)); // 4 is not present in this array so indexOf returns -1
})
})
});
When i run mocha the test passes.
But when i start my normal server i get: ReferenceError: describe is not defined
.meteor/packages/meteor-tool/.1.3.5_1.1wj76e8++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280
throw(ex);
^
ReferenceError: describe is not defined
at meteorInstall.test.mochatest.js (test/mochatest.js:3:1)
at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:153:1)
at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:82:1)
at project-i18n.js:6:1
at .meteor/local/build/programs/server/boot.js:297:10
at Array.forEach (native)
at Function._.each._.forEach (.meteor/packages/meteor-tool/.1.3.5_1.1wj76e8++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
at .meteor/local/build/programs/server/boot.js:133:5
I have a feeling that meteor wants to run the test on startup but can't find mocha stuff.
So what to do?
You need to rename the /test folder to /tests.
From the official Meteor Testing Guide:
The Meteor build tool and the meteor test command ignore any files
located in any tests/ directory. This allows you to put tests in this
directory that you can run using a test runner outside of Meteor’s
built-in test tools and still not have those files loaded in your
application.
You could also consider renaming your test files with extensions like:
*.test[s].*, or *.spec[s].* -- So your file could be named mocha.test.js.
Such files are ignored by Meteor build tool as well.
Looks like the test file is somehow invoked when the server runs. It should not be included anywhere in the server code.
If you can't figure out what's happening, you can try to debug the server and put a breakpoint at the "describe" line - try to see how you got there.
I'm completely new to sails, node and js in general so I might be missing something obvious.
I'm using sails 0.10.5 and node 0.10.33.
In the sails.js documentation there's a page about tests http://sailsjs.org/#/documentation/concepts/Testing, but it doesn't tell me how to actually run them.
I've set up the directories according to that documentation, added a test called test/unit/controllers/RoomController.test.js and now I'd like it to run.
There's no 'sails test' command or anything similar. I also didn't find any signs on how to add a task so tests are always run before a 'sails lift'.
UPDATE-2: After struggling a lil bit with how much it takes to run unit test this way, i decided to create a module to load the models and turn them into globals just as sails does, but without taking so much. Even when you strip out every hook, but the orm-loader depending on the machine, it can easily take a couple seconds WITHOUT ANY TESTS!, and as you add models it gets slower, so i created this module called waterline-loader so you can load just the basics (Its about 10x faster), the module is not stable and needs test, but you are welcome to use it or modify it to suit your needs, or help me out to improve it here -> https://github.com/Zaggen/waterline-loader
UPDATE-1:
I've added the info related to running your tests with mocha to the docs under Running tests section.
Just to expand on what others have said (specially what Alberto Souza said).
You need two steps in order to make mocha work with sails as you want. First, as stated in the sails.js Docs you need to lift the server before running your test, and to do that, you create a file called bootstrap.test.js (It can be called anything you like) in the root path (optional) of your tests (test/bootstrap.test.js) that will be called first by mocha, and then it'll call your test files.
var Sails = require('sails'),
sails;
before(function(done) {
Sails.lift({
// configuration for testing purposes
}, function(err, server) {
sails = server;
if (err) return done(err);
// here you can load fixtures, etc.
done(err, sails);
});
});
after(function(done) {
// here you can clear fixtures, etc.
sails.lower(done);
});
Now in your package.json, on the scripts key, add this line(Ignore the comments)
// package.json ....
scripts": {
// Some config
"test": "mocha test/bootstrap.test.js test/**/*.test.js"
},
// More config
This will load the bootstrap.test.js file, lift your sails server, and then runs all your test that use the format 'testname.test.js', you can change it to '.spec.js' if you prefer.
Now you can use npm test to run your test.
Note that you could do the same thing without modifying your package.json, and typying mocha test/bootstrap.test.js test/**/*.test.js in your command line
PST: For a more detailed configuration of the bootstrap.test.js check Alberto Souza answer or directly check this file in hist github repo
See my test structure in we.js: https://github.com/wejs/we-example/tree/master/test
You can copy and paste in you sails.js app and remove we.js plugin feature in bootstrap.js
And change you package.json to use set correct mocha command in npm test: https://github.com/wejs/we-example/blob/master/package.json#L10
-- edit --
I created a simple sails.js 0.10.x test example, see in: https://github.com/albertosouza/sails-test-example
Given that they don't give special instructions and that they use Mocha, I'd expect that running mocha from the command line while you are in the parent directory of test would work.
Sails uses mocha as a default testing framework.
But Sails do not handle test execution by itself.
So you have to run it manually using mocha command.
But there is an article how to make all Sails stuff included into tests.
http://sailsjs.org/#/documentation/concepts/Testing
I recently started working on a Rails app that has a large amount of QUnit tests already in place for testing ember. I have been charged with the task of setting the app with a CI (I decided to use CodeShip). The issue I currently face is that the only way for me to run the qunit tests is to go to http://localhost:3000/qunit. I need to setup a way to run the tests from the command line. I have done a large amount of research, and have tried at least 10 different solutions but non have managed to work.
Currently I am attempting to use teaspoon but it I have not managed to get it to work. Any help would be much appreciated. Please let me know if I need to post more information about the setup.
node-qunit-phantomjs gets the job done easy enough and is standalone, not a Grunt-, Gulp-, whatever-plugin:
$ npm install -g node-qunit-phantomjs
$ node-qunit-phantomjs tests.html
Testing tests.html
Took 8 ms to run 1 tests. 0 passed, 1 failed.
...
$ echo $?
1
TL;DR
Use out-of-the-box qunit command (do npm install -g qunit beforehand), so you don't need additional dependencies.
Extending a bit Arthur's answer because he mentioned only simplest case which works only for simplest projects.
As mentioned on QUnit page, there is built-in possibility to run tests from command line. There is no need to install additional weird frameworks on top of QUnit!
npm install -g qunit
qunit # Will search for tests in "test" directory
This works for artificial tests as on their website, but in real project you probably will have your logic in some other .js file.
Having following structure:
project
│ index.js <--- Your script with logic
│ package.json <--- most probably you'll have npm file since qunit executable is installed via npm
└───test
tests.html <--- QUnit tests included in standard HTML page for "running" locally
tests.js <--- QUnit test code
And let's imagine that in your index.js you have following:
function doSomething(arg) {
// do smth
return arg;
}
And the test code in tests.js (not that it can be the whole content of the file - you don't need anything else to work):
QUnit.test( "test something", function( assert ) {
assert.ok(doSomething(true));
});
Running in browser
This is not related directly to the question, but just want to make a reference here.
Just put both your script and tests to tests.html and open the page in browser:
<script type="text/javascript" src="../index.js"></script>
<script src="tests.js"></script>
Running from command line
With the setup described below you can try to run qunit, but it will not work because it cannot find your function doSomething. To make it accessible you need to add two things to the scripts.
First is to explicitly "import" your script from tests. Since JS doesn't have sunch a functionality out-of-the box, we'll need to use require coming from NPM. And to keep our tests working from HTML (when you run it from browser, require is undefined) add simple check:
// Add this in the beginning of tests.js
// Use "require" only if run from command line
if (typeof(require) !== 'undefined') {
// It's important to define it with the very same name in order to have both browser and CLI runs working with the same test code
doSomething = require('../index.js').doSomething;
}
But if index.js does not expose anything, nothing will be accessible. So it's required to expose functions you want to test explicitly (read more about exports). Add this to index.js:
//This goes to the very bottom of index.js
if (typeof module !== 'undefined' && module.exports) {
exports.doSomething = doSomething;
}
When it's done, first check tests.html still working and not raising any errors (testing test infrastructure, yeah) and, finaly, try
qunit
And the output should be like
TAP version 13
ok 1 Testing index.js > returnTrue returns true
1..1
# pass 1
# skip 0
# todo 0
# fail 0
I don't want to deal with node for my simple (or not) project
This is an open question and I cannot answer this. But you'll need some runner to run QUnit tests anyway. So maybe having package.json with one devDependency like "qunit": "^2.6.1" is not the worst option here. There are several 3rd-party runners: grunt-qunit, PhantomJS runnner, ember-qunit-cli, also see more on official QUnit Plugins page
What if I have class, not function?
In JS everything is a function, right :)? So no problem, just change your script exports and tests import acordingly
exports.exportedMyClass = MyClass; // in index.js
MyClass= require('../index.js').exportedMyClass ; // in tests.js
See example a.k.a. small getting started here.
QUnit now has its own CLI:
$ npm install -g qunit
$ qunit 'tests/*-test.js'
TAP version 13
ok 1 Module > Test #1
ok 2 Module > Test #2
1..2
# pass 2
# skip 0
# todo 0
# fail 0
Run qunit --help for more usage information.
You can use Grunt (task runner) for this. You would also need to install these two packages: grunt-contrib-qunit and grunt-contrib-connect
I did just recently set up a GitHub repository when trying to figure out how to run QUnit on Travis CI: https://github.com/stebru/travis-qunit-test
You're welcome to fork it and try it out for yourself.