I like the following: “scripts”: { “test”: “npm run test-node && npm run test-browser”, “test-node”: “mocha -R spec ./test/node/index.js”, “test-browser”: “mocha-phantomjs ./test/browser/index.html”} The && only runs the second if the first passes, and you can run either separately if you want. Note that npm always uses the relative mocha (inside node_modules), not the global one, … Read more
Mocha does not have any notion of a special file named helper.js that it would load before other files. What you are trying to do works when you run mocha –recursive because of the order in which Mocha happens to load your files. Because helper.js is one level higher than the other files, it is … Read more
The point is not so much that “structured code runs in the order you’ve structured it” (amaze!) – but rather as @chrisdew suggests, the return orders for async tests cannot be guaranteed. To restate the problem – tests that are further down the (synchronous execution) chain cannot guarantee that required conditions, set by async tests, … Read more
Okay so I realized that everything I was aliasing was in the src/ directory, so I simply needed to modify my npm run test script. { “scripts”: { “test”: “NODE_PATH=./src mocha ./src/**/test/spec.js –compilers js:babel-core/register –recursive” } } Probably won’t work for everyone, but that solved my issue.
A possible solution to omit Typescript checks is to access the property dynamically (Not telling wether its good). myClass[‘privateProp’] or for methods: myClass[‘privateMethod’]()
For anybody who has tried and had problems with typescript-require you may want to try ts-node. $ npm install -g ts-node $ mocha –require ts-node/register src/**/*.spec.ts It also appears that there has been some ongoing discussion about deprecating typescript-require in favor of ts-node.
What you need to do is assert that the url is in the expected state. There are many commands in Cypress that can be used to make assertions about the url. Specifically, cy.url(), cy.location() or cy.hash() may meet your requirements. Probably the best example for your use case would be this: cy.location(‘pathname’).should(‘eq’, ‘/newthing/:id’)
If you’re talking about testing it inside your controller specs, where you normally call get :index to make an HTTP request to the index action, you would instead call xhr :get, :index to make an XmlHttpRequest (AJAX) request to the index action using GET.
Mocha supports bailing after the first test failure, is that what you want? From mocha –help: -b, –bail bail after first test failure
In your app.js: if (process.env.NODE_ENV !== ‘test’) { app.use(express.logger()); } At the top of each of your mocha files: process.env.NODE_ENV = ‘test’; Update: We use this function in our import code: function logExceptOnTest(string) { if (process.env.NODE_ENV !== ‘test’) { console.log(string); } } Then, replace all your console.log(‘it worked’) with logExceptOnTest(‘it worked’). The basic trick is … Read more