My front end is an Angular 1.x project with tons of files. I basically need to validate it and find any errors that are there in any of the files. Specifically, errors that can break the page. In compiled/static type languages like Java, this is very easy, as the compiler will tell you exactly what's wrong. However, since JS is interpreted/dynamically typed, I can't figure out a way to "build" these files and find errors like I would for compiled languages. Going to every single page in the browser after I make any change is neither practical nor scalable.
I am also not using TypeScript or ES6 and it's not possible at the moment to migrate to any of them. Tools like ESLint and JSHint have also not been very successful, since they only bring out minor errors within that file. However, a lot of major code is spread over several files. Although my code is already all ES5, I thought about concatenating all JS files together in one file and running babel on it. But have it been sure how to manage dependencies during the concatenation (such as in what order to concatenate files).
This cant be the only project that uses vanilla JS and needs to be validated for errors. Anyone has any ideas on how I should go about accomplishing the task?
I highly recommend writing tests using jasmine and karma. I've found the two of these integrate really well with Angular and test driven development is highly regarded as one of the best development styles.
With all of this being said, I understand that's not what you're looking for directly because you want more of a "compiler" like solution. The closest thing that you can get to this in JS in my opinion is a linter and when combined with tests, this solution is rather good at finding errors in JS code.
I have quite huge project (production bundle file is around 400kB) written in coffee script. And I have no idea how to plan migration to ES6. I know that there are tools like Decaffeinate but I am not sure if it really works in bussiness practise.
I suppose that I can use ES6 and coffee in one project but is it possible to write components in coffee which import and use code written in ES6 and vice versa and all works in production?
Is this migration possible to be done step by step or there is no other option than doing everything in one release?
How does webpack work (proper loader)? What is the sequence? Does it firstly convert ES6 to JS (or coffee to JS) and then do all imports or import files first and then convert to JS?
Finally are there some best practices to have code written in both coffee script and ES6 in similar situation?
I'm the main person working on decaffeinate recently. It has been used on large production codebases and currently has no known bugs, so it's likely stable enough for you to use it. Still, you should convert your codebase a small piece at a time rather than all at once.
You can configure webpack to allow both CoffeeScript and JavaScript in the same project by specifying coffee-loader for .coffee files and babel-loader for .js files in your module.rules (or module.loaders for webpack 1).
If you use require syntax, importing code between CoffeeScript and JavaScript should just work without any problems. If you use JS import/export syntax, you may need to use require('./foo').default in some cases when requiring JavaScript from within a CoffeeScript file. But in most cases interop should just work even with import/export syntax.
Probably a good idea is to convert one or two files and make sure eslint, babel, and other JavaScript config are configured they way you want them to. From there, you should convert the code one or two files at a time, and increase the number of files you convert at once as you get more comfortable with it and depending on what your needs are.
One approach is to convert CoffeeScript files to JS slowly over time, converting and cleaning up the ones you touch. The problem I've seen with this approach is that it can be a very long time before you move off of CoffeeScript. It depends on your situation, but generally I would recommend running decaffeinate in larger and larger batches without focusing too much on manual cleanup, then once the codebase is 100% JavaScript, manually clean up files as you work with them.
A while ago, I wrote up some thoughts on how to think about different conversion strategies, which you might find useful:
https://github.com/decaffeinate/decaffeinate/blob/master/docs/conversion-guide.md#converting-a-whole-project
If Protractor is replacing Angular Scenario Runner for E2E testing, does that mean I will still be able to use it with Karma as my E2E testing framework ?
Not recommended by the current maintainer of Protractor:
https://github.com/angular/protractor/issues/9#issuecomment-19927049
Protractor and Karma should not be used together; instead they provide separate systems for running tests. Protractor and Karma cover different aspects of testing - Karma is intended mostly for unit tests, while Protractor should be used for end to end testing.
Protractor is built on top of WebDriverJS, which uses a Selenium/WebDriver server to provision browsers and drive test execution. Examples of pure WebDriverJS can be found here: http://code.google.com/p/selenium/wiki/WebDriverJs
And
https://github.com/angular/protractor/issues/9#issuecomment-19931154
Georgios - I think it makes sense to keep Protractor and Karma separate - for end to end tests, you want the native event driving and flexibility of webdriver, while for unit tests you want fast execution and autowatching of files.
UPDATE. Here is a simple package I've created to add minimal Karma setup to any project with one single command npm install min-karma.
I'd like to clarify some possible misconceptions about Karma and Protractor. Karma FAQ actually does refer to Adapter for Angular's Scenario Runner, which, however, seems to be abandoned, with Protractor being recommended instead.
Karma
Karma is a test runner that will run the JavaScript files specified in you configuration file explicitly or using node-globs. (For non-JavaScript external templates, Angular's Unit Testing Guide recommends using Karma html preprocessor to compile them into JavaScript first.)
These can be all your source files, some of them, some of them plus some additional files or files irrelevant to your project, only providing some extra configuration - you name it!
You can have multiple karma config files for different purposes, which you can run in parallel or one-by-one. Each karma process launches its own set of browsers (these are currently available).
This feature of Karma to run only a set of files is what makes it perfect for fast tests running in background upon each source file edit, and get immediate feedback, which is brilliant! The only negative is the "noisy" error reporting that will hopefully improve!
Karma is not only for unit tests
Unit test is for a single unit of your source code. In Angular's case a typical unit is Angular Component (Service, Factory, Provider, Controller, Filter, Directive etc). Remember to keep your Controllers thin, so too many unit tests for latters is a red flag.
In a unit test, every other units of code, on which this unit depends (so-called unit's dependencies) should not be tested at the same time. Instead they should be "mocked", e.g. replaced by something simple like dummy instances. Angular provides great mock environment support. Ideally you want to see all those mocks directly inside your tests, so you never need to wonder where all those dependencies come from.
Karma is just as useful for Integration Tests, where a group of source code units is tested together, with only some of their dependencies being mocked. It is important to remember that any dependency is by default provided from your source code modules (as long as those modules either injected directly in your tests, or they are dependencies of other modules injected (in which case you don't need to inject them, but no harm to do so). The mocked dependencies will override the provided ones.
Running Fast and Frequent is the main feature of Karma. This means you want to avoid any server requests, any database queries, anything that can take longer than fractions of seconds. (Otherwise it will NOT be fast!) Those long processes are ones you want to mock. This also explains why it is a bad practice to put raw low level services like $http directly inside your controllers or any complicated business logic units. By wrapping those low level outside communication services into smaller dedicated services, you make it much easier to "mock them away".
What Karma does not do is running your site as it is, which is what End-to-End (E2E) testing is. In principle, you could use Angular's internal methods to recreate the site or its pieces. Which, for small pieces, can be useful, and a fast way e.g. to test directives.
It is, however, not recommended way to throw complicated code inside your tests. The more you do it, the more chance is that you make errors in that code instead of what you are actually testing.
That is why I personally dislike the often mentioned complicated way of testing methods using low level methods like $http. It works cleaner to isolate any reference to low level methods into dedicated methods of your own, whose single responsibility is to make http requests. These dedicated methods should be able to work with real backend, not a fake one! Which you can easily test - manually or even perfectly fine with Karma running with another special config, as long as you don't mix that config with the one usually used to run Karma regular and fast.
Now, having your dedicated small services tested, you can safely and easily mock them to test your other logic and put these tests into your regular Karma setup.
To summarize. Use Karma to run any set of JavaScript files. It is (should be) fast. You don't see your complete app, so can't test the final result effectively and reliably. Would I run it with Protractor? Why would I? Running Protractor would slow down my tests, defeating the purpose of Karma. It is easy to run Protractor separately.
Protractor
Protractor is:
an end-to-end test framework for AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.
So Protractor does exactly what Karma doesn't - run your real final application. This reveals its both power and limitations:
Running complete application is the only reliable final test that your application works as expected. You can write up complete user story scenarios and put them into your tests!
But it is harder to track errors without isolating individual units of your source code. This is why you still need Karma to test your JavaScript code first.
Now would I want to run Protractor with Karma? I surely can run them in separate terminal windows, in parallel. I could, in principle, have them share test files if I need to, but normally I'd rather not. Why? Because I want to keep my tests small with single dedicated purpose.
The only exception would be a file defining testing macros useful for both runners. This, however, would not be a test file but a macro definition file.
Other than that, I like a clear separation between my tests. Those to be run frequently and fast, and those for the complete app. That makes a clear separation between when using Karma and when Protractor.
Karma is a test runner provided by the Angular team, Karma will execute your tests in multiple browsers which shall ensure that our application is compatible in all browsers.
Unit Test for angular js can be used karma + jasmine
Jasmine is a javascript unit testing framework and will provide us with utilities to test our application. This works best on the Angular framework and thus, our choice of “automated unit testing tool”.
https://github.com/shahing/testingangularjs
And Protractor is an end-to-end test framework for Angular and AngularJS applications.
Protractor runs tests against your application running in a real browser, headless browsers , cross browser testing and can be hosted on saucelabs.
https://github.com/shahing/Protractor-Web-Automation
Yes, you can use karma and protractor together. Karma is used for unit testing the component you created using angular command you can test those components using karma.
Protractor is used for end to end test. It is mainly used for UI testing.
I'm trying to grasp the basics of Jasmine (and BDD/TDD I guess). The examples I have seen does not resemble any realistic scenario of a web application, and have a hard time relating to it.
Are Jasmine tests done aside (separately) from working on the JavaScript that will be deployed? Manually copying tested/validated code.. Or does Jasmine compile to standard JS used for production?
Cheers
Jasmine is a framework for testing JavaScript code. Just like testing Ruby on Rails code, the tests don't become part of the production code. They are in the same repo and are run but they aren't minified into project.js or whatever your build process is. As part of your test run process, you can do headless tests using PhantomJS (headless webkit) and have it run on your CI server and so forth just like any other test.
I have worked on a bunch of projects this way. There has been a trend of seeing JavaScript has an enhancement layer that doesn't really need to be tested but today JavaScript is so much more. It is critical to test it if your application needs to work.
I would like to run unit tests of my JavaScript code in Cruise Control. We currently use nUnit, and I see that nUnit has a javascript library. How do I write unit (not UI) tests in JavaScript using nUnit?
The best way to automate JS tests and include them in continuous integration process is to use JSTestDriver. It is very fast, can test your scripts in all kinds of browsers, can be easily integrated in IDE (How To ntegrate JsTestDriver in Visual Studio), and what is more important - this is simple comsole application, which can be easily be executed from nant script.
The example of solution with JsTestDriver tests is here.
You can do this with JSUnit. Their JSUnit Server allows you to run scriptable JavaScript unit tests within a Java virtual machine (JVM).
You can use Rhino, which is a Javascript runtime written in Java (IIRC, the command-line is something like java -jar Rhino.jar script.js).
This is especially useful if your tests don't require a browser.
Don't forget to analyze your JS code with JSLint !