A quick disclaimer: I am not having issues, I am simply asking for guidance. I don't feel like the other topics provide a guiding point towards a particular style of testing or library rather than just helping other with their actual choice of library and style.
Hey guys! I was thinking, is there anyone in here that could provide me with some guidance for unit testing? What kind of testing do I want (I am a newbie)? e2e, tdd, bdd etc.? Any particular recommendations for libraries and good practices? I am currently working on a React Redux-Saga project and a node backend that we'd like to start testing as well. Is there library that we can use for both or do we need two different since it is essentially two different projects (Client, Server).
There are plenty of test runners out there, I would recommend using Jest its easy to setup full featured and has good documentation and maintained by Facebook. Enzyme is the de facto standard for parsing react components and traversing the DOM, although is just a wrapper around Reacts native test utils.
https://facebook.github.io/jest/
https://github.com/airbnb/enzyme
You don't need different testing libraries for client and server code at a unit level. Although for end to end testing / integration testing you do need a different runner generally one that includes selenium, although there are some great alternatives out there at the moment.
Here is a doc I put together outlining some React testing fundamentals
cypress.io looks like an interesting new platform for writing end to end test without the need for selenium making it faster and more stable.
jest is a very good option if you're working with both nodejs and react.
For a good practice, I would recommend trying to apply Clean Architecture so that your source code will have good separation of concerns and testability.
I want to premise that I'm aware of Ember QUnit (recently covered at EmberConf) as well as using PhantomJS so please read my points in question closely if you're thinking of marking as a duplicate.
My goal is to run unit tests from the command line, similar to a mocha test might run
mocha simple_test.js
and see the results in the form of a command line reporter.
testing ember modules in isolation. I would like to be able to new-up an ember object, route, or controller without the context of a running ember app (perhaps some kind of ember test harness) and run assertions against that module.
testing ember modules in the command line (avoiding browser reporters like QUnit or headless browsers like PhantomJS)
I already have integration and acceptance tests using a combination of karma and phantomjs, I would like to see if I can compliment with more unit tests. Has anybody come across a unit test setup similar to to what I listed above or is it not really possible and/or productive?
Update
The ember guides list unit testing strategies here:
http://emberjs.com/guides/testing/unit/
In my opinion, these seem more like integration tests.
Yeah I do this with my application. You might like to look at the new testing guides in the ember site's documenation if you haven't already seen it (it went live last week sometime). I helped edit it. It's pretty good! :-)
Good luck and let me know if you need any more help, like I say, I do unit tests all the time on all parts of Ember. The hardest so far for me has been components because they're neither integration nor unit, really... they're like a hybrid: isolated integration unit tests that still require large parts of ember and rendering in the view.
I run headless using guard, jasmine and qunit. Jasmine's my preference and I've been moving over from qunit slowly.
http://emberjs.com/guides/testing/
Also I noticed that what you seem to want is to isolate the units outside of even ember itself. To do that, I'd put your code in separate javascript libraries... otherwise you'll have troubles: afterall how are you going to unit test a piece of code without Ember present if it uses Ember?
We've just started developing a web app with AngularJS and we're having some problems with testing it properly so we could use some advice.
Generally, there are the following components to test:
Web API
Angular Controllers
Angular routing
HTML rendering and Angular binding of Controllers to the HTML elements
How does one test all of this with minimal effort and no, if possible, overlap?
For any database-centric application, complete integration testing (i.e. with a live server, connected to a database loaded with data) would be particularly messy because there would have to be a process that generates sufficient data for all tests and resets the DB and tests would have to be careful not to modify each other's data. (if I'm missing something here please let me know)
Given the above point, I'm assuming it is best to sever the link between server and client and run the Angular tests using mock data only.
Also, I'm assuming that if E2E testing takes care of all possible scenarios, unit testing controllers is redundant as their values are bound to the model (and would thus be testing all of 2, 3 and 4 above). Unit testing would only be helpful in very complex controllers or to test services and directives.
However, we could not find any information on how to mock stuff with $httpBackend on a per-test basis like you would do in unit tests, using expect*(). Angular docs seem to suggest using when*() plus the occasional passthrough() when necessary.
But, this poses the aforementioned problem of creating test data for all scenarios and you'd probably need to reset the in-memory DB before each test to be sure the tests are not affected. Also, you're losing the safety of using $httpBackEnd.expect*() which checks that there are no missing or redundant calls to the server - This would suggest to me that it would also require unit testing controllers to check this.
Can someone provide a detailed testing strategy for AngularJS apps that addresses the testing of the 4 components above as well as the concerns written above?
Not sure - since your angular app is theoretically decoupled from your backend, there's no particular reason that angular tests and backend tests need to be commingled. I would test them separately, with each test suite assuming that the other component works fine. (So when testing angular, you assume that the server will work as expected.)
Unit tests - they provide more depth than E2E tests. It's easier to verify specific conditions the code will face. It's also easy to mock out all dependencies as necessary and test just the component the unit tests is interested in. Unit tests don't concern themselves with how the UI works, or that the right data is bound correctly, but rather than the business logic of the app is correct.
(and 4) E2E tests - less granularity, focusing on making sure the UI looks as expected from an end user perspective. You are right that it's messy to test against a live database (although some people enjoy the safety provided by a full end-to-end integration test), and so you should use $httpBackend to mock out the server.
Refer this https://www.sitepoint.com/unit-and-e2e-testing-in-angularjs/.
If your service/factory uses the http service to call a remote API you can return fake data from it for unit testing.If you are starting a new Angular project consider using Protractor for E2E tests.
At the moment I'm working on a JS library for a webservice, you can compare it with Twitter Anywhere. Now i want to make it more test-driven.
It's not easy to test because it has to work on every site that wants to make use of it, and of course with every browser.
How can i test the library efficiently?
All the API requests and responses are in JSON, is there a good way to test these calls?
I know about Cucumber and js-test-driver.
Greetings,
Chielus
Javascript language is dynamic by nature, so it is really test-driven friendly. I've recently got a little experience with javascript testing. I've rewrote major javascript components using TDD and got clear desing and more compact code!
unit test framework of choice is qUnit. It is very easy to start with testing.
functional test framework of choise is funcunit.
I did a blog post of testing REST api with FuncUnit here.
If you need some examples of tests and implementation, you can check my github repository.
Don't ask questions, just start testing :)
If you know about jsTestDriver I think you've already found a good solution?
You can use it to automatically launch your tests in multiple browsers and return success or failure.
This sets it apart from other tools that use headless browsers, as with jsTestDriver you're running your tests in real browsers, which seems to meet your requirements.
jsTestDriver comes with its own limited assertion framework but you can plug others into it including QUnit, YUI and Jasmine.
You said above in relation to Jasmine, "I don't think i can do BDD, because it's a library that has to work with all kinds of sites.". I'm not sure what you mean by this?
Jasmine provides all the assertions to let you do the same tests as QUnit. It also lets you 'spy' on Ajax callbacks, intercept the JSON to examine or even alter it, then pass it on to your default callback. With this you could check the JSON response then check again when your UI has reacted to it in the right way.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My main JavaScript framework is jQuery, so I would like my unit test and mocking frameworks to be compatible with that. I'd rather not have to introduce another JavaScript framework.
I am currently using QUnit for unit testing and Jack for mocking, but I am pretty new to the whole unit testing of JavaScript.
Is there a better tool to suggest? What has worked for you?
I think that Jack is the best mocking framework for JavaScript as of the time of this writing. The main reason is that what's right for JavaScript is not likely what is right for a strongly typed language such as Java.
Many JavaScript mocking frameworks are inspired by Java mock frameworks (such as the excellent JsMockito, for example). But the problem with these is that they require dependency injection, because that's about the only reasonable way to use mocking in Java. But in JavaScript, there are many ways to use mocking, and you are not forced into using dependency injection everywhere.
For example, with JsMockito, you have to make mocks and then pass those mocks into your software-under-test (SUT). The SUT has to directly call the mocks. Therefore, you're forced to code the SUT as a constructor or function that takes in all its dependencies as parameters. (Sometimes, that's a fine way to implement it, but not in every case. The tail is wagging the dog if your mocking framework's design forces your implementation approach.)
In JavaScript, it's very easy to "hijack" any function. Therefore, there are tons of ways to build something such that you can mock parts of it without explicitly injecting its dependencies into it. For example, Jack lets you mock any function, whether it is public or on a local object. From there you can spy on it, stub it, or express expectations on it. The key point is this: once you've mocked a function, any calls to that original function will instead be directed to your mock. In other words, your mocks will still get used even though the original, un-mocked function was called. As a result, you are not forced to inject dependencies, although you certainly can do so in those cases which call for it.
JavaScript is a different language than Java (and C#, etc.). It allows for different implementation idioms. Dependency injection is still one valuable tool in the toolbox in JavaScript, but it is not the only game in town any more. Your mocking framework needs to know and respect that fact. Jack and a couple of others do, but of the ones that do, Jack appears to be the most mature and feature-rich.
QUnit
jqUnit
Writing JavaScript tests with QUnit and jqUnit
QUnit is the unit testing framework for the jQuery JavaScript framework. The testing framework itself uses the jQuery library, but the tests can be written for any JavaScript and do not require the code to use jQuery.
jqUnit is a modified version of QUnit that adds in the setup, teardown, and assert functions that are more typical of an xUnit framework, and encapsulates everything in one global variable.
The visual interface of the testrunner page is nice, allowing you to drill down and see each assert in every test method. Writing tests is fairly easy, and you can run the test code directly on the testRunner page [8]. This allows for easy and visible DOM testing.
QUnit: MIT or GPL (choose) jqUnit: MIT License
Pros
Asynchronous support
Good for DOM testing
Tests always run sequentially in the order they are added to a suite
Debug on test page using firebug
Syntax is similar to JUnit if using jqUnit, but simple to learn if using QUnit
Cons
Automation would be difficult to implement
I'm not sure why no one has mentioned JsTestDriver! It has to be the one of the only JavaScript testing tools that actually work like you'd expect them to if you've used unit testing tools in other languages.
Running tests can be done without touching a browser, you can integrate it with IDE's, and you can integrate it with Continuous integration systems... Oh, and it's fast, and can run tests in multiple browsers at the same time.
You can also use other testing frameworks like YUITest with it, making it even better.
YUI Test
TDD With YUI Test
YUI Test is the test framework for Yahoo’s User Interface (YUI) library. It is used by Yahoo to test its own library, and has syntax similar to JUnit.
Like jsUnit, YUI Test comes with its own logging console that can output information, warnings and errors in addition to the results of each test.
YUI also provides the ability to send reports on the results in either JSON or XML format.
YUI Test is BSD licensed.
Pros
Really good documentation
Active community
Regular releases
Syntax is similar to JUnit (test suites, asserts and setup/teardown)
Asynchronous support
Good for DOM testing
Tests always run sequentially in the order they are added to a suite
Cons
Automation not trivial to implement, but less difficult than other frameworks
Also check out
http://sinonjs.org/
It has test spies, test stubs, mocks, fake timers, fake XMLHttpRequest (XHR), fake server, sandboxing, and assertions
It does work along with QUnit and that has been a plus so far.
This is a pretty good review of mocking frameworks available for JavaScript:
http://testdrivenwebsites.com/2010/05/06/java-script-mock-frameworks-comparison
I use the Screw Unit test framework and I've written my own mocking library called jsMocha which has been in heavy use in the company I work at for over 6 months.
For mocking in JavaScript, take a look at qMock, a framework a colleague and I wrote to complement our use of QUnit. Although the latter is great for unit tests, it doesn't allow for very effective async/business logic testing. We haven't 'tagged' any release as stable, but there's some decent documentation on there, and if you checkout the SVN repository you'll see qmock itself has unit tests behind it which are fairly self-explanatory.
Oh, and to automate testing as part of the build, we used a simple Selenium script to navigate through our testsuite (one testing page per JavaScript file), and 'listened' for a pass or fail CSS class (added by QUnit). This works headless as well for Internet Explorer and Firefox 2, AFAIK.
For Firefox development, I have fallen in love with UXU, based on MozUnit, but it is still active. It has nice features, like a mock server and sleep / yield methods.
CrossCheck seemed extremely powerful when I looked at it, but we've not incorporated it into our build process at this time. It has the advantage of being browserless, and thus should work well in an automated build-and-test scenario.
http://thefrontside.net/crosscheck
I know you are asking for jQuery-compatible frameworks, but I want to throw script.aculo.us into the mix for completeness. They have a unit test suite that isn't bad.
JsUnit is run from either the browser, through its Eclipse plug-in, or automatically through an Ant task. You create an HTML page with a bunch of test functions, which must be named with the prefix ‘test’, include the JavaScript file you are testing. When any assert within a function fails, the entire function fails and stops executing. There is no guaranteed order in which these tests are run. You can create setup() and teardown() functions.
License: GPL, GLPL, and MPL
Pros
Automation is relatively easy to implement
A lot of functionality
Syntax is similar to JUnit
Cons
Not great for DOM testing since it runs tests inside an iFrame.
No guarantee that tests will be run in the order they are written.
Can’t use Firebug on the testrunner page. Need to have another tab open with the actual test code.
We've been using jsspec. It's very nice if you like rspec and BDD. I just saw an article by Justin Gehtland on using it "headless" as well.
You could try HtmlUnit which had a jQuery compatible release over a year ago.
The advantage of HtmlUnit is that it isn't driving a browser, so it is fast.
The downside is that it isn't driving a browser so there are some JavaScript things that won't work. But offsetting that they can run the jQuery tests so the JavaScript support might be good enough for what you need.