I use Jest with superset for testing working Koa's urls. All test placed in __test__ folder and I testing only request urls from my routes.
How can I use coverage for mark testing routes? Maybe I can use something special comments in routing source file or use some middleware for mark working routes?
Usually test coverage implies which part of code that your test imports was actually executed.
In your case it sounds like you are doing integration testing, and you want to know how many endpoints out of all endpoints are working.
If integration testing is what you really want, you could have an sdk of sorts, and then track line coverage of that. Separate your testing network requests from your integration tests.
Related
I'm making an API for a website (this is open source you can find the repo and look by yourself here : https://github.com/PirateSeal/Operation-Green-Axe-2)
I'm making tests suites with jest and supertest and i'm using knex to connect and talk with my db.
My problem is that i can't run multiple tests suites because the first one is "locking" access to my db.
In each of my tests files I implemented the BeforeAll() and AfterAll() methods to create and teardown my db and instead of doing that for each test, i'd like to create a setup file that will run before all tests suites and after all.
I read about jest setup file but i didn't understand how to use it.
Can you help me please ?
(this is my first question here btw pls be kind :) )
Until now, I've done all my testing with just Jasmine and jQuery to automate the browser. I am starting to explore Karma but it seems to be set up only for unit tests that involve loading HTML fragments as test fixtures and I find no way to load a whole web page. Am I missing something or is this simply the wrong tool for what I am trying to do?
From the karma FAQ's section:
Can I use Karma to do end to end testing?
Karma has primarily been designed for low level (unit) testing. If it's an AngularJS app, you can use Karma with the karma-ng-scenario plugin. However, we recommend Protractor for high-level testing.
Typically, loading a whole web page goes beyond the scope of single units of code: you need to spin up a browser, load the page and make your actions and assertions. End-to-end testing frameworks like Protractor, Nightwatch.js or Webdriver.io might be more suitable for this specific case.
You can do integration testing using the following toolchain:
Karma ➔ Mocha ➔ Mocha-CasperJS ➔ CasperJS.
Check out the mocha-casperjs package.
I have some Angular/Rails app where Rails part is just JSON API, all front works is doing by AngularJS. I've made model/controller test already using RSpec, and now I want to make some integration tests. Earlier I use request test (with Capybara, Selenium) of RSpec to test my pages/JS, but Angular is often tested by Karma/Jasmine, and I don't understand what way is preferred in Angular/Rails app. Please, give me advice, may be you share some experience with me. Thanks.
First of all you should test everything wisely. I will recommend great series of blog posts from the link below.
Since you are already familiar with RSpec, keep using it for your rails tests like models, controllers, request, etc.
For your Angularjs tests, karma and Jasmine are great choices. But Rails uses Sprockets for asset management so configuring karma can be a little bit tricky. For Rails and Jasmine I wrote a rake task. To run javascript tests you should simply run rake karma:start. I shared the link of the gist below.
The gist contains 2 files. You should put them:
karma.rake -> lib/tasks
karma.unit.js -> spec/javascripts/
Finally you should run feature/acceptance tests with Capybara.
Testing Series Intro
The Gist of Rake Task and Karma Configuration
I have got javascript tests running in visual studio using Resharper and Jasmine. It all works fine. Now however I want to run an integration test. After looking into this I just can't work out whether I should be using Karma or PhantomJs or both? And whether they link to resharper?
I then have to run all my tests on the continuous integration server using Team City. Doesn't seem like there is a clear logical way to architect front end testing from dev right through to the CI server.
For example do I really need to use Karma locally and on the CI server? I don't want to because it is not baked into visual studio and I will have to keep opening the command line and running my tests manually. This will annoy other developers and they won't bother running them I imagine. Help!
We are using Team City by the way....
Neither of these test runners are connected to Resharper in any form. I don't think there is a one and only "correct" way of running Jasmine tests in TeamCity currently - for all approaches I am aware of there is a bit of assembly required.
Personally I am using a combination of PhantomJS and the Jasmine TeamCity Reporter which works like this:
Get a list of unique test URLs from server - each of these test suites will use the Jasmine TeamCity Reporter to log results
for each test URL dynamically generate a test JS file to be used for phantom and write it to disk
use PhantomJS to run the JS file which now will load the test suite page and its test result will be written to console where they are picked up by TeamCity.
I am trying to choose a setup for testing a webapp that uses Backbone and RequireJS.
I will try to do most of my unit testing from javascript and I am in doubt whether it is better to load my whole app before calling the testing framework or to use RequireJS to dinamycally load just the modules that are being tested by each test.
As this site is just for Q&A and not open to discussion, I will reformulate: Do you have any strong argument against not loading the whole app upfront when unit testing?
The best way is to test each of your Models/Collections/Views separately in unit test. Starting the whole app in a unit test would it made really hard to test all cases for a module. As you mention requireJS you should also mock most of the dependencies of a module using squireJS.
But you should additionally have some integration tests where you test the behavior of the whole app in a headless browser using a tool like selenium, casperJS or capybara.
With requirejs, there are two ways for you to interpret loading upfront:
During development, where r.js is not be used, and just depend on configuration on requirejs.config
After r.js optimization, where the modules can be restructure by r.js configuration