Does anybody using protractor with jasmine to do API testing. While searching for this I get to know that using frisby.js we can do API testing. But, my doubt is that whether protractor or jasmine directly supports/provides functions for API testing. Did anybody tried this? If so, what is the approach that I need to follow ?
Thanks in advance.
Protractor is meant for e2e testing and e2e tests are supposed to test the flow of an application from user standpoint, in spite of that you should test your API calls not directly but rather through testing user actions and if actions perform as intended it means the API that they rely on work.
If you want to do tests for API to catch errors early without having to run full e2e test suite you should use frisby.js as you've mentioned to confirm all APIs are A-OK and you can follow then with e2e tests when you are sure that all should be working.
IMO it's better to use the tools for what they were designed.
Related
I understand that Jest is a unit testing tool for developers used for JavaScript. Is Jest a browser based testing tool similar to Selenium or a functional testing tool?
As you mention, Jest is meant to be a unit testing tool. Normally you'd write small tests for parts/components of a web-page. I'm not exactly sure what you mean by "Is Jest can be used as Browser based Testing tool?" but I've found there are two relevant areas where Jest can come into contact with browser based testing
You can use a virtual DOM (like JSDOM) to render your components and test them in an environment similar to a browser. These are still unit tests but you'll have access to window and document and can test things like document click, window navigation, focused element etc.
You can debug your Jest tests in browser. Follow the instructions here if that is what you want. I've tried this but it was really slow and not very useful for me so I wouldn't recommend it
You can probably render your entire application and test it with Jest, but I wouldn't recommend that either. Jest tests should be designed to run fast and should only tests small units of your code. If you try and build tests that take a long time to run then there is an argument stating that your unit tests will become useless and developers will eventually not run them anymore.
If you are looking for tests that start an actual browser and click around like a user then have a look at Selenium which I would think is the most common approach these days
This npm library can be integrated with your jest tests to run them in a browser :) :
https://www.npmjs.com/package/jest-browser
I can't say how good it is/what the cons are but it looks like it is worth a try!
Yes, you can use Jest Preview (https://github.com/nvh95/jest-preview) to debug your Jest test in a browser like Google Chrome.
You don't have to debug a long HTML text when using Jest Preview anymore.
Read more at https://www.jest-preview.com/docs/getting-started/intro
I am new to Jest. Looking Jest as a unit testing framework, How can it be used for testing a website. I could found Jest examples applies to validation of Java script business functionalities but how can it be used for a website testing similar to Selenium. It would be really great if somebody could provide an update.
Thanks in Advance.
gtlkanth
Jest can't be used for end to end integration tests. It is focused on testing isolated features of your application's logic.
https://github.com/facebook/jest/issues/560
For nodejs backend server code Unit Testing, I am using node-qunit with grunt.
Is there any code coverage tool using node-qunit module?
Maximum code coverage tool I am seeing needs headless browser support, ex. PhantomJS, but if I run using this, then I get syntax errors for nodejs keywords, like "ReferenceError: Can't find variable: require" etc.
So which tool I can use for code coverage for nodejs backend code testing using node-qunit.
If you're solely testing backend code, there's no need to run the tests in a headless browser like PhantomJS. For running code coverage analysis in node, I can recommend istanbul.
But I'm not sure if it works out of the box with node-qunit. However mocha is a popular node.js test runner with a qunit-interface, and qunit-mocha-ui delivers QUnit's assertions for mocha. So you could migrate your tests with only little effort.
This is probably a really dumb question, but I'm not sure. If I have a node.js application and a much of tests built with Mocha, I can run them on my server no problems, using mocha. However, is there any way to invoke the unit tests through a browser and just pipe the results to the page? For development, I'd like to have a page on my website that shows the results of the tests.
Every time I search for how to do this, it's testing the actual browser code I'm finding (the dom, the UI etc), but it's actually just that I want to see the results of the tests run server-side but from the browser!
Thanks in advance!
Sure, create a route in Express that executes mocha and returns the result to the browser. Take a look at child_process.fork to execute mocha: http://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
And don't forget to turn it off before going into production!
Separately, I would highly recommend to you the concept of continuous deployment, and specifically the service CircleCI, which for $19 automatically runs all of your tests every time you push to Github.
I'm writing tests for an Express.js app and I don't know how to choose between unit tests and integration tests.
currently I experimented with:
unit tests - using Sinon for stubs/mocks/spies and Injects for dependency injection to modules. with this approach I have to stub MongoDB and other external methods.
I thought about unit testing the individual routes and then using an integration test to verify that the correct routes are actually invoked.
integration tests - using Supertest and Superagent, much less code to write (no need to mock/stub anything) but a test environment should exist (databases, etc..)
I'm using Mocha to run both styles of tests.
how should I choose between those two different approaches ?
You should probably do both. Unit test each non-helper method that does non-trivial work. Run the whole thing through a few integration tests. If you find yourself having to do tons and tons and tons of mocks and stubs, it's probably a sign to refactor.