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?
Related
I'm presently working on a very large modular web app. where the front-end is implemented using AngularJS 1.x. The project is about 2 years old and there was never any unit testing done as part of the development process. There is now a requirement to add unit testing for at least 85% of the Angular codebase. The general consensus seems to be: "Use Jasmine/Karma or Mocha/Chai/Sinon" for unit testing.
My concern after looking at the usual testing libraries is the amount of work that will need to be put in for data mocks and unit testing in general. It seems excessive and almost as bad as re-developing the application. Recently I've also read a couple of articles regarding the general overhead of unit testing with sophisticated testing libraries like Jasmine (see: https://medium.com/javascript-scene/why-i-use-tape-instead-of-mocha-so-should-you-6aa105d8eaf4#.1bzhv0q1f)
The part about using Tape JS to test got me wondering whether that is easily done in Angular 1.x. I've very new to unit testing and wanted to find out whether anyone has done unit testing using Tape with Angular 1.x? Is this possible?
Thoughts on pros/cons/experiences with Tape and generally unit testing in Angular, would be greatly appreciated.
Thank you.
Following up on my comment.
I think the reason everyone uses Jasmine is that they want to test their code through the AngularJS interface, and that requires a test harness.
For example - let's say you are writing a test for a component. You will have to bootstrap the component's angular.module. You'll also have to create an instance of the component's controller through $componentController. And if the controller requires any dependencies, you'll have to make sure those dependencies also have their angular.module bootstrapped.
Jasmine does all this great.
However, Jasmine can very quickly become unwieldy. It introduces all sorts of global variables. There is a ton of repetition involved with BeforeEach. And to run your tests, you'll probably have to use Karma, which requires a lot of dependencies and is pretty darn slow.
I think you could skip all this and just use TapeJS if you were okay with testing your code as plain old javascript. I think this approach is okay for unit tests -- but for e2e tests, you should dive into jasmine/protractor.
For example, my AngularJS applications are written in Typescript with class syntax. Every component controller and service is a typescript class that is also exported. So to test with TypeJS, all you have to do is import the typescript class, create an instance of it, and voila. You now have access to all the methods (assuming they are all public), and you can test that input/output works as expected.
This should work fine for AngularJS 1.5+, but if you have an app with a lot of directives, I'm not sure how that would work.
I do hope this helps. Spending days trying to get test runners to work is the worst.
Read more:
https://ponyfoo.com/articles/testing-javascript-modules-with-tape
I'm starting to introduce TDD into an existing JavaScript/jQuery project.
Currently, I'm testing with Mocha and Chai under Grunt in a CLI shell in Emacs.
This works nicely for the parts of the code that are side-effect-free, synchronous, don't use jQuery, etc.
I've found many online articles addressing individual issues in setting up a more inclusive test environment, but I've not managed to find a good getting-started guide, without diving into the weeds of competing libraries and setups.
I don't need a "best" answer, nor anything too fancy. I don't even need mock button presses or user-input; I'm happy just testing my handler code.
Just looking for a guide or set of recommended best practices to test client-side JavaScript code where:
The existing code uses jQuery and AJAX;
The test environment should be running continuously;
The test environment should be launched from my gruntfile. Or, I'd be ok moving to gulp or any other similar driver.
Ideally, I'd like the tests to be running in an Emacs buffer. But, if need be, I'd be ok having it running in another window that I can stick in the corner of my screen;
Tests should run reasonably fast. I want them to trigger automatically on every file save.
I think I'm describing a very vanilla set of test requirements, so I'd expect there to be common answers. But, my search-fu must be low today because I'm not finding what I want.
If you're using Mocha and Chai, then you already have the basics set up.
If your code under test modifies the document, you can substitute an artificial document for your tests (via jsdom).
If your code under test fires Ajax calls and you'd like to test them, you can use sinon to put a fake XMLHttpRequest provider. sinon also offers a convenient mock for setTimeout and the family.
If the code under test uses jQuery, then you can either separate the jQuery-dependent part, or just run jQuery on the server using the jsdom document. jQuery installs with npm easily.
If all of this seems not realistic enough for your purpose and you'd like a more true environment, you can have a look at karma - it's an automation tool that can open a browser in the background, run any tests inside and report the errors in the console. It's much slower than mocha but you get to run your code (and tests) in a real browser, perhaps even several browsers at the same time.
Both tools have their places, e.g. you could use mocha for testing vanillajs and simple DOM modification (also e.g. React components if you're into that), and resort to karma for writing slower, more realistic tests that depend more on real browser behaviour.
I am developing an application by using nodeJs + yo angular-fullstck and my starting point is the BDD and TDD.
After a research over various sites i decided to do this by using cucumber-js and Jasmin respectively over karma runner.
All the tests were red, I made them green and I thought that I am ready to go for real tests.
My problems seems to be focused more on cucumber-js rather on Jasmine.
I am trying to setup some tests that would open a real browser (not a headless one) and unfortunately this seems to be harder than I thought.
Could someone give me some hints of how to do this?
Is the karma-cucumberjs a correct choise for what I want to achive?
Thanks
My favorite test runner which launches a full browser session is Protractor. It was simple to setup and I haven't had much trouble with it yet.
The tests I write are still in Jasmine and an example one looks like this.
describe "Angular Test Scaffold", ->
it "displays my GitHub name", ->
browser.get("app/index.html").then ->
expect(element(By.css("#githubName")).getText()).toBe("Test user")
I wrote a little about how I setup my first project with protractor on my github site. I hope it will be useful.
I want to do a smoke test in order to test the connection between my web app and the server itself. Does Someone know how to do it? In addition I want to do an acceptance tests to test my whole application. Which tool do you recommend?
My technology stack is: backbone and require.js and jquery mobile and jasmine for BDD test.
Regards
When doing BDD you should always mock the collaborators. The tests should run quickly and not depend on any external resources such as servers, APIs, databases etc.
The way you would want to make in f.e. Jasmine is to declare a spy that pretends to be the server. You then move on to defining what would be the response of the spy in a particular scenario or example.
This is the best aproach if you want your application to be environment undependent. Which is very needed when running Jenkins jobs - building a whole infrastructure around the job would be hard to reproduce.
Make spy/mock objects that represent the server and in your specs define how the external sources behave - this way you can focus on what behavior your application delivers under specified circumstances.
This isn't a complete answer, but one tool we've been using for our very similar stack is mockJSON. It's a jQuery plugin that does a nice job both:
intercepting calls to a URL and instead sending back mock data and
making it easy to generate random mock data based on templates.
The best part is that it's entirely client side, so you don't need to set up anything external to get decent tests. It won't test the actual network connection to your server, but it can do a very good job validating that type of data your server would be kicking back. FWIW, we use Mocha as our test framework and haven't had any trouble getting this to integrate with our BDD work.
The original mockJSON repo is still pretty good, though it hasn't been updated in a little while. My colleagues and I have been trying to keep it going with patches and features in my own fork.
I found a blog post where the author explain how to use capybara, cucumber and selenium outside a rails application and therefore can be use to test a javascript app. Here are the link: http://testerstories.com/?p=48
I'm writing up unit tests for a app but I'm having difficulty keeping track of what scenarios I've tested for in each method.
I'm currently using qunit and creating a testing directory for each object that I'm unit testing and a single file for each method I'm testing but how do you get a good overview of all your tests in an easy to digest form?
Ideally I'd like to have something
which could take my unit tests and add the test description next to the function which it relates to in the code itself so when in the code I can see the tests I've got for the method straight away
have some sort of easy to read overview of all my tests
Does anyone have any recommendations of tools or practices which may help out with this problem?
The projects I've worked on have all been Server+Client projects, where we had a suite of unit tests for our server side code, and wanted to integrate our client side unit tests into that process.
In that case, I have written a "Unit Test" in my server side code that opened up each QUnit test in a browser, then scraped the DOM for success/failure entries, and called Assert(false, text_scraped_from_dom). Then all of my qUint tests were run as part of my CI build and showed up as failing tests there.
I have done this for Java with httpunit, and for .NET with watin.