I am trying to run Mocha tests within the Meteor test framework for a certain subset of code in a Meteor project. In particular, this is an internal library that does not actually use any Meteor features, and the test just needs to read in a file, do some computations, and compare results (no server or database or anything). So in theory, this could be its own package with its own testing framework. However, I would still like to use the Meteor test framework if possible just so that I don't need to run two sets of tests. Also, it would be nice to avoid maintaining the dependencies associated with a second test framework. So I have one general and one specific question along these lines:
Which testing package (see http://guide.meteor.com/testing.html#mocha or recommend another) is most appropriate for running "plain" Mocha tests, i.e. most similar to just running mocha from the command line? It seems to be dispatch:mocha, but it "only runs server tests", which doesn't seem ideal. It would help to get some clarification on exactly what "only runs server tests" means and how dispatch:mocha differs from plain mocha.
I was able to get a test sort of working with dispatch:mocha, but there were two problems:
I had to put the test file in the server directory, even though it is shared client and server code.
In order to read test data from a file, I had to put the test data in the private directory and use Assets.getText(). I initially tried (and would prefer) to put the test data in the same directory as my test, but the test gets built in some kind of way that ignores my test data in that case (I can give more details if this is supposed to work).
Is there some way I can avoid the above?
Related
I've googled around for an answer but have yet to turn up anything of use. Does anyone know why attempts to run ember test at best result in a message that reads:
Built project successfully. Stored in "/Users/.../tmp/class-tests_dist-H42JePnK.tmp".
If your tests won't run at all, here are a few things to look for:
Check for a testem.js file. It is essential and contains the instructions and configurations that the Ember CLI needs. Deleting it will cause your app to build and 0 tests to run.
Check to make sure your testem.js file is valid/complete. You can test this by doing ember init and then choosing option d (diff) to see what is different between your app and a brand new app.
Your tests are also available in the normal browser. Go to http://localhost:4200/tests and see what happens there. Perhaps it will give some clues.
Similar to above, try ember test --server and see if you get different results.
Create a fresh app with ember new and try doing ember test. It can sometimes be easier to compare a fresh app instead of doing the ember init diffing.
Try switching the browser you are using for testing (unlikely to be the problem in this case, but sometimes works). For example, run the tests with headless Chrome instead of PhantomJS. The most recent release of the Ember ClI has the testem configuration that you need to try headless Chrome.
I have working CI/CD pipeline using MSBuild with "run unit tests" step and separated build server for this.
Its pretty hard to instal other tools like karma or npm for running javascript tests separately, so I want to run all javascript tests from .net unit test.
So, basically I want to create something like
[Fact]
public void Test()
{
var file = LoadJSFile();
// how can I impleemnt this method?
RunJSTests(file);
}
So, I have two questions:
1. Are there any existing tools for this (like nuget package)?
2. Maybe, I'm going in totally wrong direction and I should spend my efforts to creating separate CI step "Run Javascript Tests"?
My gut feel is that in the long run a separate CI step for the JavaScript tests would be better, but there's some ideas you could investigate / follow from this post How to run QUnit test and get back test result in C# via JavaScript callback?.
The reason I suggest a separate CI step is to decouple the JS from the C#, so that if in the future you switched from pure JS to, say, Angular or typescript, the migration of tests would be simpler. Similarly any migration of C# to F# or, more likely, MSBuild to Jenkins or other CI server could be done more flexibly.
If there's little bingle info for option 1 then that suggests option 1 is somewhat niche, but I don't want to pre-judge that, but if so go with option 2 for now - you can always implement option 1 in the future if necessary and feasible.
I got a question regarding build controllers of Visual Studio.
I got a project where I run multiple C# unit test. I currently implemented Javascript Unit tests to the project and I want to let the unit test be part of the build.
Several tutorials are available on the internet. One of them I used as guideline towards running JS intergrated within my TFS which is running on a buildserver.
The problem that I have is that the tutorial is saying that I should check in the files (of Chutzpah) and add the source file to the build controller. Here is my problem. Due to the fact that I do not want to affect all the other unit tests and build processes I can not modify the build controller. I can change any build definition but I can not change the "Version Control Path to custom Assemblies". So I was wondering is there alternative method where I still can make sure that JS unit tests are part of the build but not changing the version control path for the whole project?
I hope I stated my situation clear enough.
You can enable your build process to leverage binaries that you have
uploaded to your Team Foundation Server, for example:
Assemblies that contain your custom workflow activities.
Third-party unit test frameworks. See Run tests in your build process.
Custom MSBuild tasks
To enable your build processes to leverage these kinds of code, upload
the binaries to the folder (or any of its descendant folders) that you
specify in the Version control path to custom assemblies box. MSDN
So, if you haven't configured this path of your build control. It's easy, you just need to set a sever path. This will not affect other unit tests and build processes cuase they didn't even use this path before.
If there is aleady a server path, you just need to add the files mentioned in the tutorials into the source control with the same path. Just like a share folder, when the build definitions need the file, the build control will automatically find and call it in this path. When you set or modify the value in this box, the build server automatically restarts to load the assemblies.
I am just trying to get my head round unit testing in Javascript and RequireJS. I am building a web-app and obviously only want to have tests run in development not production builds.
Questions:
Do you just test when you want to, or do you have JS tests running
on every page load when in development?
If tests are only on demand
then how do you trigger your tests to run? Query strings (eg.
?testing=true) or something like that?
I just need an idea of how people go about testing in development. I am using BackboneJS, RequireJS and jQuery on the front end with a NodeJS/ExpressJS server on the backend.
For a Backbone project at work we have a maven build process that runs our automated javascript tests through jsTestDriver, and we read the results with Sonar. I usually run the tests manually (with 'mvn test'), but I could easily tell maven every time I save a file, for example. I wrote a post that shows how to integrate QUnit, Requirejs, and code coverage with JSTD that is independent of Maven: js-test-driver+qunit+coverage+requirejs. It also contains links to a QUnitAdapter that is way more up-to-date and developed than the one on the jsTestDriver site. I'll update this post when I manage to write about how I got jsTestDriver working with Maven and Sonar. Hope it helps.
Grunt is a popular JS build tool. There's something called grunt-watch that can monitor certain files for change, and execute tasks accordingly. You could easily run unit tests with something like this on every save.
Usually end-to-end tests take longer, and we use the CI for that. I've seen a presentation on Meteor TDD that does end-to-end tests after every save though.
There are many end-to-end test frameworks, and they can run in a headless browser like phantom js using a build tool like grunt. Some frameworks open an actual browser to run the tests, but run via command line and report results using XML.
If you break out your components enough, the tests could have a small enough scope to run on each save.
For some core code I use JsUnit + Rhino on build server. For more complex bits (usually interface) I use selenium (it also runs on build server). I don't test anything on page load, I only use not-compressed versions of scripts.
I don't any solution for integration tests.
We have a rich web client. Our controllers and service facades are written in coffeescript (JavaScript) and jquery. In the past they would have been java.
To run our JavaScript jasmine tests from Jenkins/Hudson, we use java's junit and htmlunit to load a test oriented jsp page which includes the jasmine specs.
When the Htmlunit tries to run, it blows up trying to getPage() probably because of an XML parser class path which is extremely challenging to track down in our world.
We just want to be able to run our JavaScript tests from Jenkins and have it report failure if a JavaScript test does not pass. We are just using jsp and htmlunit in order to run JavaScript tests. Can we load the JavaScript tests and javascript code into a JavaScript engine with Jenkins as the thing that kicks it off? If so, how?
Sounds like you're in a Java environment. My jasmine-maven-plugin might be a good fit.
Jasmine Reporters would also be a solution. It has instructions for running headlessly via PhantomJS for example, and it can generate JUnit XML so Jenkins can understand the test results natively, graphing test count, duration, and failure over time.
Also, the "xvfb-run" wrapper often provided with xvfb is a great help here, so you can do "xvfb-run phantomjs.runner.sh ..." in a truly headless environment.
I've previously solved this problem by running the tests with a node.js plugin called jasmine-node
This solution of course requires node.js and a few node modules to properly run the jasmine tests. There is no real browser running the tests, but an emulated one using a module called jsdom, which basically creates a headless browser, and more specifically, a DOM, which the tests can interact with.
There's node modules for jQuery, underscore and propably other too, so these can be tested too. You can even skip the whole browser emulation if you'd rather run the tests in a browser, though I find it too cumbersome compared to automated Jenkins testing.
jasmine-node generates jUnit test reports, which Jenkins can interpret just fine.
I just realized there is some jenkins-jasmine-node plugin that might ease this process.
Grunt is your friend
use grunt http://gruntjs.com/
with grunt jasimine https://github.com/gruntjs/grunt-contrib-jasmine
with nodejs http://nodejs.org/
on jenkins using https://wiki.jenkins-ci.org/display/JENKINS/NodeJS+Plugin
got this setup and it's really nice, plus this gives you a place to start making your build server do other nice things such as deployment, unit testing, etc you know, other nice things
Can you use selenium? That would actually use a real browser then and get as close to the real environment as possible.