Develop Reference

How to unittest Firefox 57 WebExtensions?

The older Firefox "Add-ons" API had a built-in unittest layer sdk/test that allowed testing. This doesn't seem to be available any more.
Additionally the use of "package/require" allowed code to be separated into "js code-only" packages that were testable using node.js. The new, highly structured javascript doesn't share this.
My priorities are (highest to lowest):
Algorithms, "business logic", e.g. parsing input data - no APIs needed - just JavaScript
Internal logic - e.g. background scripts interacting with settings, etc.
UI interactions - I can live without this, but would be nice to test
So how do people test their WebExtensions?

Check out webextension-geckodriver for a worked example of functional testing.
If you want to test interaction with the webextension API you can either do it live (have a test page for your extension and get geckodriver to visit it, for example) or use a fake like sinon-webextension through webextension-jsdom.
To unit test algorithms, just import the functions using jest, mocha, or whatever node unit testing framework you prefer or add them to a test page that you can visit in the browser.
A complete, but old, worked example of webext testing is here: example-webextension.
An example of tests in a real webextension using another fake: vim-vixen

It is still possible to run unit tests in NodeJs.
To illustrate the idea, let us take a look at the Cliqz extension, whose source code is open (Github link: cliqz-oss/browser-core). In comparison other extensions that I have seen so far, the code base is quite large.
In other words, it is not a toy example, but a realistic use case. The drawback, of course, is that due to the complexity, it is harder to understand how the test setup works (how mocking works, the integration into the build system, etc).
To get an idea how tests look like, here is one example:
source: query-sanitizer.es
test: query-sanitizer-test.es
To explain the details of how the mocking works is hard because you would need to dive deep into the build system. From a high level perspective, you will notice that in the test it uses a function called describeModule, which does all the mocking of dependencies.
In the implementation of describeModule, you can see that it uses systemjs to dynamically load ES modules. That trick makes it possible to run the unit tests with NodeJs.
My priorities are (highest to lowest):
Algorithms, "business logic", e.g. parsing input data - no APIs needed - just JavaScript
For these kind of tests, the unit test infrastructure described above is the preferred way. For local development, NodeJs is used to run the tests.
Internal logic - e.g. background scripts interacting with settings, etc.
This is not so different. The idea is still that you can mock dependencies and then do classical unit tests.
It might require some work to allow dependencies to be replaced. As mentioned, as the code base in this example has to run in different environments (e.g., Firefox, Chrome, Edge, ReactNative), platform APIs have to be abstracted (that includes also browser APIs).
UI interactions - I can live without this, but would be nice to test
For testing the UI, there are additional integration tests. I do not want to go into details, but there are examples in the code.
What is important is that the integration tests are not executed with NodeJs, but they require a real browser environment (e.g., Firefox, Chrome). In addition, a local HTTP server is started which can be used to mock API calls.
As a side-note, linters are extremely useful and in comparison easy to setup. Also consider using a typed language (TypeScript), especially when the project becomes bigger and more people are working on it.
You will still need tests, as static analysis will not be able to find logical bugs. However, it helps to eliminate certain types of simple bugs like typos and the overhead (fixing linter errors or adding type annotations) is not very high.

Test Driven JavaScript Development with Django vs Node.js

I have a web project coded 80% in JavaScript and 20% in Django without a single unit testing as I rushed for Minimum Marketing Features. Now that the project is getting funded, I decided to invest some time to introduce TDD. I had a great deal of inspiration from this KickStarter-funded tutorial.
http://www.letscodejavascript.com/
The author uses Node.js, Jake, Lint, Nodeunit, and Karma to simplify the whole integration process. The server/client tests in all major browsers is done in a single command and I was really hooked to this idea, but it requires switching to Node.js.
I've searched for TDD in Django and ran into this tutorial that makes use of Selenium.
http://www.tdd-django-tutorial.com/
However this TDD was primarily based on unit testing in server. Here are the questions.
Can multiple client JavaScript testing be done in Django/Python?
I assume the answer is no since js files are nothing more than static library in Django. Correct me if I'm wrong.
Is it worth using Node.js just for the sake of TDD Javascript?
My logic was either you use Python or Node.js for the server, but since tools like Karma and Buster.js requires Node.js, I was wondering whether setting up the Node.js alongside Django just for multiple client testing is plausible choice when considering lower cost of maintenance.
Thank you :D

You can take a look at using selenium in your django test suite. Django's official docs cover this in moderate detail
To answer your question about Node.js - I would say that it's probably not worth the complexity to add node.js SOLELY for the purpose of running unit tests. Also, since your javascript is likely built to run in a browser, it's less likely that things will break down if you use a tool like selenium (which runs the code in an actual browser, providing a python scripting interface).

Frameworks and tools for UI testing of ExtJS based web apps

I would like to test a web app that was drastically redesigned to use ExtJS to drive its UI.
I have done some online searching but couldn't find any recommendation for a good framework to handle it properly.
Up till now we have been using WatiN to create tests.
Note that we do not own the web app code.
What are the best options currently available?

You should look at using Siesta, it's a unit testing and functional testing tool designed to help you test Ext JS and Sencha Touch (and it's also used by Sencha internally to test Ext JS itself). Since Siesta knows a lot about Ext JS you can write expressive tests using Component Query instead of CSS and get much more robust test compared to simpler tools described in other answers in this thread. Here's a sample test script in plain JS:
t.chain(
{ click : ">>textfield[name=user]" },
{ type : "Mike[TAB]Password" },
{ click : ">>button[name=loginbutton]" }
);
DISCLAIMER: I work for the company that created it.
http://www.bryntum.com/products/siesta/

Are you looking to do a straight functional test of your web page or are you looking to narrow your tests specifically to the JavaScript in ExtJS?
If it's the former (functional at the UI level), then WatiN/Watir/Webdriver ought to work for you. (If they're not working then I'd love to get more details around specific issues you're running in to.)
If it's the latter then you might investigate Jasmine which gives a lot of interesting capabilities around unit testing your JavaScript at the UI layer.
(If it's functional testing, you might also check out Telerik's Test Studio for functional automation. I'm the Evangelist for that tool, so I'm a bit biased...)

You may want to look at RIATest.
Version 5.0 fully supports ExtJS testing. ExtJS UI widgets are first class citizen in RIATest. This means that unlike other HTML testing tools you do not need to write tests that manipulate the HTML DOM elements. The tests in RIATest operate in terms of ExtJS UI widgets.
Examples of RIATest scripts that work with ExtJS widgets:
The following clicks on an ExtJS button with label "Next Page":
ExtButton("Next Page")=>click();
And the following does drag-n-drop of a row from one ExtJS tree to another:
ExtRow("Controller.js")=>dragAndDropTo(ExtTreePanel("#tree2")->ExtRow("Custom Ext JS"));
And this collapses the header of an ExtJS box:
ExtBox("Feeds")->ExtHeader("FeedsВ")->ExtCollapser()=>click();
(All sample code above is from real test scripts that run on ExtJS sample applications).
RIATest also knows when to automatically wait for ExtJS AJAX to finish, so if your UI does dynamic content downloading the tests will auto-magically wait until data is received from server.
(Disclaimer: I am a RIATest team member).

Sahi is an automation and testing tool I have recently come around as I am in a similar search as you... Selenium hasnt worked for me (as it hasnt for many around the web... havent found anything to make it work... dynamic IDs and other Ext related particularities mess with it apparently)...
take a look at sahi maybe it will be useful... www.sahi.co.in (I have no relation, I discovered it recently and found it useful).

You want to do Functional Testing. Selenium is a good choice. It has API implementations in a slew of languages (Java, Ruby, Python) and it uses Webdriver under the covers.

Ranorex can handle Ext-Js as well, although turning it into first class citizens will require some custom coding. The secret in general is to avoid using id's for object recognition, as they change around and use innertext property instead.

Personally found using xpath with extjs flaky in places.
You're better off (in Java) writing a method which uses a JavaScript component query to pull out the element id. (if it has one)

Continuous JavaScript Testing

Does anyone know of a good JavaScript testing tool which integrates automated testing with your Testing Framework of Choice. I am aware of TestSwarm (which is not automated testing) and Travis-CI (which isn't really available for closed-source projects).
Any other ones out there?

You can use Selenium:
Its test can either be generated by its IDE, or can be written in high level languages such as Java, PHP, etc.
Its can be instantiated from a Command-Line.
Its can be integrated with continuous-integration servers like Jenkins (In-build plugin).
The fact, that it can be instantiated from command-line (preferably written in java), makes it integrable by any CI Server

Two that I know of (although I'm not sure they are really meant for this purpose...) are Simple Test js and the MIT project Sikuli. Sikuli is great for making a cursor click on things and test out the user interactions. Neither one of these naturally will integrate well with your testing framework of choice but they will certainly allow you to write unit tests. Hopefully someone else will know of a better solution.

Developing UI in JavaScript using TDD Principles

I've had a lot of trouble trying to come up with the best way to properly follow TDD principles while developing UI in JavaScript. What's the best way to go about this?
Is it best to separate the visual from the functional? Do you develop the visual elements first, and then write tests and then code for functionality?

I've done some TDD with Javascript in the past, and what I had to do was make the distinction between Unit and Integration tests. Selenium will test your overall site, with the output from the server, its post backs, ajax calls, all of that. But for unit testing, none of that is important.
What you want is just the UI you are going to be interacting with, and your script. The tool you'll use for this is basically JsUnit, which takes an HTML document, with some Javascript functions on the page and executes them in the context of the page. So what you'll be doing is including the Stubbed out HTML on the page with your functions. From there,you can test the interaction of your script with the UI components in the isolated unit of the mocked HTML, your script, and your tests.
That may be a bit confusing so lets see if we can do a little test. Lets to some TDD to assume that after a component is loaded, a list of elements is colored based on the content of the LI.
tests.html
<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
<ul id="mockList">
<li>red</li>
<li>green</li>
</ul>
</body>
<script>
function testListColor() {
assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
var colorInst = new ColorCtrl( "mockList" );
assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
}
</script>
</html>
Obviously TDD is a multi-step process, so for our control, we'll need multiple examples.
yourcontrol.js (step1)
function ColorCtrl( id ) {
/* Fail! */
}
yourcontrol.js (step2)
function ColorCtrl( id ) {
$$("#mockList li").forEach(function(item, index) {
item.setStyle("backgrond-color", item.getText());
});
/* Success! */
}
You can probably see the pain point here, you have to keep your mock HTML here on the page in sync with the structure of what your server controls will be. But it does get you a nice system for TDD'ing with JavaScript.

I've never successfully TDDed UI code. The closest we came was indeed to separate UI code as much as possible from the application logic. This is one reason why the model-view-controller pattern is useful - the model and controller can be TDDed without much trouble and without getting too complicated.
In my experience, the view was always left for our user-acceptance tests (we wrote web applications and our UATs used Java's HttpUnit). However, at this level it's really an integration test, without the test-in-isolation property we desire with TDD. Due to this setup, we had to write our controller/model tests/code first, then the UI and corresponding UAT. However, in the Swing GUI code I've been writing lately, I've been writing the GUI code first with stubs to explore my design of the front end, before adding to the controller/model/API. YMMV here though.
So to reiterate, the only advice I can give is what you already seem to suspect - separate your UI code from your logic as much as possible and TDD them.

See also: JavaScript unit test tools for TDD

I've found the MVP architecture to be very suitable for writing testable UIs. Your Presenter and Model classes can simply be 100% unit tested. You only have to worry about the View (which should be a dumb, thin layer only that fires events to the Presenter) for UI testing (with Selenium etc.)
Note that in the I'm talking about using MVP entirely in the UI context, without necessarily crossing to the server-side. Your UI can have its own Presenter and Model that lives entirely on the client-side. The Presenter drives the UI interaction/validation etc. logic while the Model keeps state information and provides a portal to the backend (where you can have a separate Model).
You should also take a look at the Presenter First TDD technique.

This is the primary reason I switched to the Google Web Toolkit ... I develop and test in Java and have a reasonable expectation that the compiled JavaScript will function properly on a variety of browsers. Since TDD is primarily a unit testing function, most of the project can be developed and tested before compilation and deployment.
Integration and Functional test suites verify that the resulting code is functioning as expected after it's deployed to a test server.

I'm just about to start doing Javascript TDD on a new project I am working on. My current plan is to use qunit to do the unit testing. While developing the tests can be run by simply refreshing the test page in a browser.
For continuous integration (and ensuring the tests run in all browsers), I will use Selenium to automatically load the test harness in each browser, and read the result. These tests will be run on every checkin to source control.
I am also going to use JSCoverage to get code coverage analysis of the tests. This will also be automated with Selenium.
I'm currently in the middle of setting this up. I'll update this answer with more exact details once I have the setup hammered out.
Testing tools:
qunit
JSCoverage
Selenium

What I do is to poke the Dom to see if I'm getting what I expect. A great side effect of this is that in making your tests fast, you also make your app fast.
I just released an open source toolkit which will help with JavaScript tdd immensely. It is a composition of many open source tools which gives you a working requirejs backbone app out of the box.
It provides single commands to run: dev web server, jasmine single browser test runner, jasmine js-test-driver multi browser test runner, and concatenization/minification for JavaScript and CSS. It also outputs an unminified version of your app for production debugging, precompiles your handlebar templates, and supports internationalization.
No setup is required. It just works.
http://github.com/davidjnelson/agilejs