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.
Related
I'm writing a web app with my friend. He writes the Fronted, I write the Backend. Problem is that there is no way of me testing my code if my friend haven't wrote the integration yet, because we bundle the code in web pack and run it on a dev server. My question is, is there a way that I could test my typescript code (call functions with parameters) in chrome console, like I could test unbundled javascript?
The professional answer is: Don't do that!
Test the actual server using Postman.
Write unit tests for your api-handling client code that intercepts calls to the server (because those aren't unit tests), via jest or some other unit testing library.
Write unit tests for the front end that doesn't actually touch your middle-code.
Convert unit tests to assertions where you can, because case coverage beats code coverage and you can't possible think of everything during unit tests.
Write integration tests that are user-centric, not widget centric.
And that's hard but you'll be glad you did it... if you can do it without the project dying because of it! For a project that is just you and a friend, that may be a mighty big "if"!
So the realistic answer is probably: Write... or get your friend to write... an ugly-but-functional page you can use to enter some values and click a button to submit it, and then add debugger as a statement near the start of the button code. debugger is a hardcode breakpoint that dev tools will pause at.
Once that's written and working you should be able to modify it as needed. ...just remember not to let that page escape into production.
I have the task of creating a Test Harness for a Cordova built mobile application.
Thus far, all of my test scripts are automation scripts....
Is it viable to test the entire application using solely automation tests?
I cannot find any documentation regarding normal logical testing of the source code? Am i missing something can some one point in the right direction I'm quite lost.
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?
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 work for a team of ASP.net MVC and they are using Cruisecontrol, nUnit and nAnt for the automated testing and build. I am new to the group and i handle the Javascript layer and i am looking for ways to incorporate my work with my teams workflow.
Are there any possoble way to do this?
Thanks
A few thoughts:
There is JSUnit, a unit test framework for JavaScript. I used it a 2 years ago and it was pretty good. Something better may be out there now.
I assume they're using source code control of some form, and that Cruise Control monitors the repository. If so, then just make sure your JavaScript is kept in the same repo, so it will trigger builds, automatic kickoff of unit tests, etc.
If you have portions of your JavaScript layer that can only be tested in a browser, think about using Selenium or a similar tool to create a kind of automated tests that drive the browser through various scenarios. I'm sure there is a way to kick these off from Cruise Control.
Just a couple of days ago, John Resig announced a JavaScript unit test automator he's working on called Test Swarm. It's just now going into alpha, but it might be worth watching.
I've found JSUnit to be a pretty good unit testing tool for javascript.
You might also consider using javascript lint (link below). It's a static code analyzer (not a unit testing tool) and I've had good experiences with it in the past. It's not as thorough as some of the complied language lint tools, but it can save you from making some truly evil mistakes in javascript. You can run it from the web page or the command line, so it should wire into a build process pretty easily.
http://www.javascriptlint.com/index.htm
As #Charlie mentions, JsUnit is a good choice for automated unit testing, via JsUnit Server.
QUnit is a new unit testrunner, is highly customizable, I've been playing with it and you can integrate and check the test results through browser automation tools like Selenium.
That's pretty much what we have at the moment, but a very promising project is emerging right now, TestSwarm by Mr. John Resig, check this blog post for more information (and sign up for the alpha release!):
JavaScript Testing Does Not Scale
Looks really interesting:
(source: ejohn.org)