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.
Related
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?
I am working in some development team. We have unit tests in our programm. There are many tests in it. Each test covers one module. In common, one developer is working only on one or some modules (but not many) per one task. To improve unit tests speed I use focused specs (I use Jasmine and our app is AngularJS app).
The problem: sometimes I forget to remove focused specs. I commit and PR with fit/fdescribe calls in programm. It can cause problems for me and other developers in the future. Obvious example: developer is developing :), he made a mistake, he started tests and only focused specs worked, since he worked on another file - it is a problem - there will be mistake but he wouldn't see it.
Is there any methods to automatically find focused specs in my tests and warn developer about it? Our team is using CI with grunt running on it. Grunt has tasks for jscs and jshint. Maybe it is somehow possible to create own rules to prevent this mistake?
I would setup a git hook and utilise grunt-ddescribe-iit.
For now, let's use grunt-githooks to setup the git hook.
grunt.initConfig({
githooks: {
options: {
'pre-push': 'grunt ddescribe-iit'
}
},
ddescribe-iit: {
files: [
'test/**/*.js',
'app/**/*.spec.js'
]
}
});
That's a very contrived example of how I imagine it would work, I haven't utilised ddescribe-iit myself (though, like you - I should be!) nor have I used grunt-githooks.
Looking through how they're both put together however, my established guess is that this would be a fairly painless process to set up.
Like you, we are also utilising a CI system and it has always been a pain when a build passes, but it only ran a couple of chosen tests. Using a git hook that screams in your face before pushing, kills the problem at the root I reckon (without introducing watchers and additional processes during the development step).
All at the amazing cost of development overhead of 0.
edit: this answer assumes that you are utilising grunt as a task runner. there are equivalents for gulp.
Does anyone have a good strategy for adding TypeScript to a continuous integration system?
I'm planning on compiling it in my build and then running unit tests against it's generated JavaScript.
However, I'd like to add code standards checking for the TypeScript. Any ideas?
Thanks.
The TypeScript team are deliberately reserving judgement on the official coding standards because they want to see how people use the language in real life. Anecdotally, people seem to be following the JavaScript naming conventions, i.e. ModuleName, ClassName, functionName.
You can write your unit tests in TypeScript (tsUnit) or JavaScript (Jasmine, QUnit et al).
How you integrate it with CI depends a little on the framework and on the CI platform. I have integrated tsUnit tests with Visual Studio and TFS using the MS Script Engine to execute the tests. If you want more details on this particular set up I am happy to share.
One option is to set up TSLint and integrate it into your build process.
In my case (an Angular 2+ app), I added an npm task to run TSLint. Then the CI system (VSTS for me) executes that npm task. The CI system fails the build if TSLint detects any errors. The TSLint task I'm using comes from Angular's quickstart project. Here: https://github.com/angular/quickstart/blob/master/package.json [Notice the "lint" script]
Also note that TSLint's rules are configurable, so you can customize the coding standard to whatever you want to use.
Your question is vague; it's difficult to give a precise answer.
For integrating TS compilation into your build system, you'll want to simply invoke the TypeScript command line compiler (tsc.exe) on your .ts files. This will output the JS and you can run your unit tests against those.
Regarding TS code standards, I don't think there's any tooling available now that look at TS coding standards, seeing as how the language went public just a few months ago.
What code quality / code coverage tools are available for Jasmine?
Working in Rails 3.2.2.
You may be able to use a combination of JsTestDriver and this Jasmine adapter to get coverage metrics.
JSCoverage is a C based tool that you run out of band from the command line..
JesCov is a Java solution that supports Jasmine. You can run it from the command line, so it should be fairly straight forward to integrate with Rails if the system has a JRE:
java -jar jescov-0.0.1.jar one.js two.js three.js
I looked into JesCov several months ago for a Grails project, but never actually tried it out, so I'd be interested in hearing your experience if you do try it.
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.