I am planning to use either CoffeeScript or TypeScript in one of my project which transcompiles to JavaScript. And I would like to use Jasmine/Mocha unit testing framework. But I could not find proper answers to below questions in google.
Which is correct, testing complied JavaScript or
CoffeScript/TypeScript and Why ?
Does it make sense to use
TypeScript/CoffeeScript to write testcases as well ?
You have to compile CoffeeScript/TypeScript in order to run it. That includes testing. So, yes, you test the compiled version. You may want to have different (smaller) compilation units for the unit tests if compiling the whole thing takes too long.
Sure. Then you get all the advantages you chose these languages for.
My doubt is which will make sense testing complied JavaScript or CoffeScript/TypeScript and Why
Either will work fine.
Does it make sense to use TypeScript/CoffeeScript to write testcases as well ?
Yes it does. Stick and a language an run with it. For TypeScript you might find this quick sample as useful : https://github.com/TypeStrong/tsproj
code: https://github.com/TypeStrong/tsproj/tree/master/src/lib
tests: https://github.com/TypeStrong/tsproj/tree/master/src/test
I don't have a better sample that is still simple :)
Related
We recently upgraded to a newer build of a JavaScript minification library.
After a significant amount of quality assurance work by the testing team, it was discovered that the new version of our minifier had an issue that changed the intention and meaning behind a block of code.
(Life lesson: don't upgrade JS minifiers unless you are really convinced you need the new version.)
The minifier is used for client side JavaScript code with a heavy emphasis on DOM related activity, not nearly as much "business logic".
A simplified example of what was broken by the minifier upgrade:
function process(count)
{
var value = "";
value += count; //1. Two consecutive += statements
value += count;
count++; //2. Some other statement
return value; //3. Return
}
Was minified incorrectly to the following:
function process(n){var t="";return t+n+n,n++,t}
While we could write some unit tests to catch some of the issues potentially, given that the JavaScript is heavy on DOM interactions (data input, etc.), it's very difficult to test thoroughly without user testing (non-automated). We'd pondered using a JS to AST library like Esprima, but given the nature of the changes that could be done to the minified code, it would produce far too many false positives.
We also considered trying to write representative tests, but that seems like a never-ending task (and likely to miss cases).
FYI: This is a very sophisticated web application with several hundred thousand lines of JavaScript code.
We're looking for a methodology for testing the minification process short of "just test everything again, thoroughly, and repeat." We'd like to apply a bit more rigor/science to the process.
Ideally, we could try multiple minifiers without fear of each breaking our code in new subtle ways if we had a better scientific method for testing.
Update:
One idea we had was to:
take minification with old version
beautify it
minify with new version,
beautify, and
visually diff.
It did seem like a good idea, however the differences were so common that the diff tool flagged nearly every line as being different.
Have you considered a unit test framework, such as QUnitjs ? It would be quite a bit of work to write the unit tests, but in the end you would have a repeatable test procedure.
Sounds to me like you need to start using automated Unit Tests within your CI (continuous integration environment). QUnit has been thrown around, but really QUnit is a pretty weak testing system, and its assertions are barebones at the minimum (it doesn't even really use a good assertion-based syntax). It only marginally qualifies as TDD and doesn't handle BDD very well either.
Personally I'd recommend Jasmine with JsTestDriver (it can use other UT frameworks, or its own, and is incredibly fast...though it has some stability issues that I really wish they'd fix), and setup unit tests that can check minification processes by multiple comparisons.
Some comparisons would likely need to be:
original code & its functionality behaves as expected
compared to minified code (this is where BDD comes in, expect the same functional performance/results in minified code)
I'd even go a step further (depending on your minification approach), and have a test that then beautifies the minification and does another comparison (this makes your testing more robust and more ensured of validity).
These kinds of tests are why you would probably benefit from a BDD-capable framework like Jasmine, as opposed to just pure TDD (ala the results you found of a visual diff being a mess to do), as you are testing behavior and comparisons and prior/post states of functionality/behavior, not just if a is true and still true after being parsed.
Setting up these Unit Tests could take a while, but its an iterative approach with that large of a codebase...test your initial critical choke points or fragile points fast and early, then extend tests to everything (the way I've always set my teams up is that anything from this point on is not considered complete and RC unless it has Unit Tests...anything old that has no Unit Tests and has to be updated/touched/maintained must have Unit Tests written when they are touched, so that you are constantly improving and shrinking the amount of untested code in a more manageable and logic way, while increasing your code coverage).
Once you have Unit Tests up and running in a CI, you can then tie them into your build process: fail builds that have no unit tests, or when the unit tests fail send out alerts, proactively monitor on each checkin, etc. etc. Auto-generate documentation with JSDoc3, etc. etc.
The issue you are describing is what CI and Unit Tests were built for, and more specifically in your case that approach minimizes the impact of the size of the codebase...the size doesn't make it more complex, just makes the duration to get testing working across the board longer.
Then, combine that with JSDoc3 and you are styling better than 90% of most front end shops. Its incredibly robust and useful to engineers at that point, and it becomes self-perpetuating.
I really could go on and on about this topic, there's a lot of nuance to how you approach it and get a team to rally behind it and make it self-forming and self-perpetuating, and the most important one being writing testable code...but from a concept level...write unit tests and automate them. Always.
For too long frontend devs have been half-assing development, not applying actual engineering rigor and discipline. As frontend has grown more and more powerful and hot, that has to change, and is changing. The concept of well tested, well covered, automated testing and continuous integration for frontend/RIA applications is one of the huge needs of that change.
You could look at something like Selenium Web Driver Which allows you to automate tests for web applications in various environments. There are some cloud hosted VM solutions for doing multi environment testing, so you don't get caught out when it works in Webkit but not in IE.
You should definitely look into using source maps to help with debugging minimized JavaScript. source maps will also work with supersets of JavaScript such as CoffeeScript or my new favorite TypeScript.
I use closure compiler which not only minifies, but also will create the source maps. not to mention it is the most agressive and produces the smallest files. Lastly you kinda have to know what's going on in minification and write compatible code, your example code could use some refactoring.
check out this article on source maps:
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
also check out the documentation for closure compiler, it's got suggestions on how to write better code for minification:
https://developers.google.com/closure/compiler/
Not a testing solution, but how about switching to TypeScript to write large JS apps like yours?
I tested it out with TypeScript and its default min engine and it works fine.
Assuming your count arg is an number.
The type script will be:
class ProcessorX {
ProcessX(count: number): string {
var value = '';
value += count.toString();
value += count.toString();
count++;
return value;
}
}
Which produces js like this:
var ProcessorX = (function () {
function ProcessorX() { }
ProcessorX.prototype.ProcessX = function (count) {
var value = '';
value += count.toString();
value += count.toString();
count++;
return value;
};
return ProcessorX;
})();
Then minified to:
var ProcessorX=function(){function n(){}return n.prototype.ProcessX=function(n){var t="";return t+=n.toString(),t+=n.toString(),n++,t},n}()
It's on jsfiddle.
If your count is a string, then this fiddle.
we use closure compiler in advanced mode which both minifies and changes code, as such we compile our unit tests as well, so you could consider minifying your tests alongside your code and running it like that.
"Tab"ing the REPL gives me a list of functions, but often working with multiple languages, I forget the signature of common functions like fs.open, etc. Is there anyway to show these in the REPL?
Thanks to auto-complete in editors, they seem to be fine. But REPL for writing some quick script, I have pull up the node documentation each time for simple things.
Is there a better way to deal with this?
This semi official project developed under the node umbrella on GitHub offers a few improvement over the default REPL while used interactively:
https://github.com/nodejs/repl
Syntax highlighting is enabled for the input, basic functions signatures are displayed as hints.
As stated in this issue, its future is still uncertain, but it's already quite usable in the current state: https://github.com/nodejs/repl/issues/46
Is it possible to load only a subset of all custom commands in a nightwatch test suite?
E.g:
Test suites/test files:
component1Tests1.js
component1Tests2.js
component2Tests1.js
component2Tests2.js
Custom commands:
component1Commands.js
component2Commands.js
Component1TestsX files/tests should see only component1Commands. The situation for Component2TestsX is analogical. This is needed because of the eventual naming collision of the commands.
Thank you all in advance!
As far as I know, it is not possible, and looks more like a bad naming practice.
How would someone else know what does the component1Commands.js do?
What if component1Commands.js already do the same thing that component2Commands.js do?
You would be breaking the DRY principle, the main idea of the commands its to reuse the code for multiple tests. You should name it correctly. If its needed, its better to separate the whole tests into two differentes projects instead.
We recently upgraded to a newer build of a JavaScript minification library.
After a significant amount of quality assurance work by the testing team, it was discovered that the new version of our minifier had an issue that changed the intention and meaning behind a block of code.
(Life lesson: don't upgrade JS minifiers unless you are really convinced you need the new version.)
The minifier is used for client side JavaScript code with a heavy emphasis on DOM related activity, not nearly as much "business logic".
A simplified example of what was broken by the minifier upgrade:
function process(count)
{
var value = "";
value += count; //1. Two consecutive += statements
value += count;
count++; //2. Some other statement
return value; //3. Return
}
Was minified incorrectly to the following:
function process(n){var t="";return t+n+n,n++,t}
While we could write some unit tests to catch some of the issues potentially, given that the JavaScript is heavy on DOM interactions (data input, etc.), it's very difficult to test thoroughly without user testing (non-automated). We'd pondered using a JS to AST library like Esprima, but given the nature of the changes that could be done to the minified code, it would produce far too many false positives.
We also considered trying to write representative tests, but that seems like a never-ending task (and likely to miss cases).
FYI: This is a very sophisticated web application with several hundred thousand lines of JavaScript code.
We're looking for a methodology for testing the minification process short of "just test everything again, thoroughly, and repeat." We'd like to apply a bit more rigor/science to the process.
Ideally, we could try multiple minifiers without fear of each breaking our code in new subtle ways if we had a better scientific method for testing.
Update:
One idea we had was to:
take minification with old version
beautify it
minify with new version,
beautify, and
visually diff.
It did seem like a good idea, however the differences were so common that the diff tool flagged nearly every line as being different.
Have you considered a unit test framework, such as QUnitjs ? It would be quite a bit of work to write the unit tests, but in the end you would have a repeatable test procedure.
Sounds to me like you need to start using automated Unit Tests within your CI (continuous integration environment). QUnit has been thrown around, but really QUnit is a pretty weak testing system, and its assertions are barebones at the minimum (it doesn't even really use a good assertion-based syntax). It only marginally qualifies as TDD and doesn't handle BDD very well either.
Personally I'd recommend Jasmine with JsTestDriver (it can use other UT frameworks, or its own, and is incredibly fast...though it has some stability issues that I really wish they'd fix), and setup unit tests that can check minification processes by multiple comparisons.
Some comparisons would likely need to be:
original code & its functionality behaves as expected
compared to minified code (this is where BDD comes in, expect the same functional performance/results in minified code)
I'd even go a step further (depending on your minification approach), and have a test that then beautifies the minification and does another comparison (this makes your testing more robust and more ensured of validity).
These kinds of tests are why you would probably benefit from a BDD-capable framework like Jasmine, as opposed to just pure TDD (ala the results you found of a visual diff being a mess to do), as you are testing behavior and comparisons and prior/post states of functionality/behavior, not just if a is true and still true after being parsed.
Setting up these Unit Tests could take a while, but its an iterative approach with that large of a codebase...test your initial critical choke points or fragile points fast and early, then extend tests to everything (the way I've always set my teams up is that anything from this point on is not considered complete and RC unless it has Unit Tests...anything old that has no Unit Tests and has to be updated/touched/maintained must have Unit Tests written when they are touched, so that you are constantly improving and shrinking the amount of untested code in a more manageable and logic way, while increasing your code coverage).
Once you have Unit Tests up and running in a CI, you can then tie them into your build process: fail builds that have no unit tests, or when the unit tests fail send out alerts, proactively monitor on each checkin, etc. etc. Auto-generate documentation with JSDoc3, etc. etc.
The issue you are describing is what CI and Unit Tests were built for, and more specifically in your case that approach minimizes the impact of the size of the codebase...the size doesn't make it more complex, just makes the duration to get testing working across the board longer.
Then, combine that with JSDoc3 and you are styling better than 90% of most front end shops. Its incredibly robust and useful to engineers at that point, and it becomes self-perpetuating.
I really could go on and on about this topic, there's a lot of nuance to how you approach it and get a team to rally behind it and make it self-forming and self-perpetuating, and the most important one being writing testable code...but from a concept level...write unit tests and automate them. Always.
For too long frontend devs have been half-assing development, not applying actual engineering rigor and discipline. As frontend has grown more and more powerful and hot, that has to change, and is changing. The concept of well tested, well covered, automated testing and continuous integration for frontend/RIA applications is one of the huge needs of that change.
You could look at something like Selenium Web Driver Which allows you to automate tests for web applications in various environments. There are some cloud hosted VM solutions for doing multi environment testing, so you don't get caught out when it works in Webkit but not in IE.
You should definitely look into using source maps to help with debugging minimized JavaScript. source maps will also work with supersets of JavaScript such as CoffeeScript or my new favorite TypeScript.
I use closure compiler which not only minifies, but also will create the source maps. not to mention it is the most agressive and produces the smallest files. Lastly you kinda have to know what's going on in minification and write compatible code, your example code could use some refactoring.
check out this article on source maps:
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
also check out the documentation for closure compiler, it's got suggestions on how to write better code for minification:
https://developers.google.com/closure/compiler/
Not a testing solution, but how about switching to TypeScript to write large JS apps like yours?
I tested it out with TypeScript and its default min engine and it works fine.
Assuming your count arg is an number.
The type script will be:
class ProcessorX {
ProcessX(count: number): string {
var value = '';
value += count.toString();
value += count.toString();
count++;
return value;
}
}
Which produces js like this:
var ProcessorX = (function () {
function ProcessorX() { }
ProcessorX.prototype.ProcessX = function (count) {
var value = '';
value += count.toString();
value += count.toString();
count++;
return value;
};
return ProcessorX;
})();
Then minified to:
var ProcessorX=function(){function n(){}return n.prototype.ProcessX=function(n){var t="";return t+=n.toString(),t+=n.toString(),n++,t},n}()
It's on jsfiddle.
If your count is a string, then this fiddle.
we use closure compiler in advanced mode which both minifies and changes code, as such we compile our unit tests as well, so you could consider minifying your tests alongside your code and running it like that.
I need to build a automated javascript api testing framework which take a combination of Use cases from the given set of use cases and runs the tests and provides the output as pass or fail along with the use case combination.
What should be the basic approach to do so ?
If there is any existing library to do so kindly suggest the same.
QUnit would give you a good start: http://docs.jquery.com/Qunit
FireUnit would then give you qunit test output via Firebug: http://ejohn.org/blog/fireunit/
If you're looking to integrate with TeamCity, I wrote a rudiumentary library for qunit: http://qnunit.codeplex.com/
Try PreemJS, it's good for API\Unit javascript testing