how to do backbone.js UI testing - unit-testing

So I've created an require.js and backbone.js (actually marionette.js) application that basically is some sort of mobile app builder.
Now I want to create tests for it, basically testing this scenario:
Navigate to an existing project, e.g site.com/build/1234
Drag a component, check if it is added correctly.
Change properties of a component and see if they are updated correctly. I.e: I've a properties panel which lists the properties
of the selected component, than for example I've a property which
is a selectmenu and changes the size (small, medium, large). I
should be able to test this.
Now I've been searching on google, however since there are so many testing frameworks, i'm not sure which one to pick and which one provides the functionalities I need.
Potentially PhantomJS seems to be something I could use, however please advice me with some specific information.
Thanks.

if you want to actually simulate clicks, look into selenium (http://docs.seleniumhq.org/projects/webdriver/)
If you just want to test that your Backbone components(views, controllers, etc) and templates are working correctly, you can use a js test runner such as Karma (http://karma-runner.github.io/0.12/index.html) to run your tests. Sinon can mock out your ajax calls for you as well. It can use PhantomJs as a rendering engine, so you can actually render your views, and use view.$() style DOM inspection to verify the output of your views.

Related

How do I set model variables within an acceptance test?

In Ember.js, I currently want to test a UI feature present. Essentially, once a model variable changes, I expect to see a UI element appear (a checkmark). I have tried creating a model within the acceptance test but this unfortunately did not work as I did.
I just wanted to know which function to use to set model variables.
A model typically would involve unit tests, but like you've said you're testing the visual result of something being set on a model. I would recommend an integration test. If you are able to refactor (or maybe this is the case already), the part of the template into a component then you can create an ember test for the component and pass in the model set up perfectly how you would like.
If this test really does depend on the model being setup a specific way I would look at how your application sets up that model to begin with and try to replicate those actions with click and fillIn helpers. Another way is say, your application wants to setup a user but relies on a network request to do this, then you could use pretender.js and fake the response to that request so that the application's inputs are setup from the network in the way you're after.
I would really try to do this an acceptance test though, the composable nature of components allows them to be tested in stricter isolation, these tests will run faster, and you're worrying less about side effects.

Internal autolinking in Ember.js

I've tasked myself with implementing a twitter clone in Ember.js in order to get more familiar with the framework. I've hit a bit of a snag however when it comes to implementing autolinking in the tweet.
There is an existing plugin that does external links (ex. http://www.google.com) well but doesn't work well for internal links (like #handle or #hashtags) which should as it should be implemented as a LinkComponent but I can't figure out how to insert one from a helper.
source code: autolink helper (relevant unit test)
For now I have just had the helper insert a <a/> tag but this sucks as it unloads the page and fetches everything fresh from the server.
Anyone have any suggestions about how best to implement this part of my Ember app?
Figured it out myself - I converted the helper into a component and added a click listener for bubbled click events from the child links which then get passed to the router:
https://github.com/whoward/ember-twitter-clone/commit/93af68d9f504b8b8972487e6c09851d3523a3678

ember.js: prepare code to move from ember 1.x to ember 2.0

My question is: Can someone direct me in moving from controller based application to component base application?
I am building a map application for my dog training club. We are specialized in helping finding missing people.
In order to organize our training, we need an application to draw trails and add items on them etc.
I've started an app using Ember-Cli and OpenLayers-3. The application is working nicely, but I would like to move the code from controller based to component base approach.
I would like also to use more routing as at the moment, I have only one route and all user interactions are handled using actions.
I've setup a repository on github for those who would be kind enough to help me:
https://github.com/mylen/mantrailling
if you want to checkout the code and test the app localy, you'll need to modify the referer using a header mod in your navigator to use http://demo.melard.fr
You can see a beta of the website at that page :
http://recherche.utilitaire.melard.fr/beta/map
Thank you in advance,
First, we should clarify the intended uses of components, controllers and routes in ember.js.
Components are similar to Views, but they are isolated and therefore used to create reusable pieces of code, that handle the visual representation of your models.
Controllers are mainly used to decorate your models, but also to hold application state.
Routes represent you current application state. They are responsible for loading your models and to initialize your controllers.
To solve your first problem (controllers -> components), you only need to move all view related stuff, and only this, into components. Your code that decorate your model, for example the active flag of a way-point, remains in the controller. You only need to bind the data of your models/controllers to the components, via embers data binding. (http://guides.emberjs.com/v1.11.0/components/passing-properties-to-a-component)
Your second problem (use routes) is a bit harder to solve, I think. First you need to find all of the states your app currently have. After that, you should move your model loading and saving stuff into this routes.
Edit
Some references describing the problem.
https://github.com/ef4/rfcs/blob/routeable-components/active/0000-routeable-components.md
https://www.youtube.com/watch?v=QgycDZjOnIg
Edit 2
Your question is highly related to How to move ember from 1.x to 2.0, because the changes you mentioned will come along with ember 2.0.
Here are some additional links that describe how to prepare best for this upgrade.
https://gist.github.com/samselikoff/1d7300ce59d216fdaf97
https://speakerdeck.com/tomdale/ember-2-dot-0-in-practice
http://discuss.emberjs.com/t/what-is-a-good-way-to-do-this-in-ember-2-0-no-itemcontroller-no-arraycontroller/6649
You can find a lot of resources if you search for ember 2.0.
Edit 3
Here is I think the most informative source for keeping up with new Ember releases:
https://www.youtube.com/watch?v=wsydQzQF4Ww

A/B testing with ember.js

I've found absolutely nothing on Google with regard to A/B testing with a client-side framework such as ember.js.
The goal is to serve up adjusted content (different nav items, header phrasing etc.) in order to A/B test our UI/UX. I should note that nothing significant (i.e. sitemap) is changing, just some minor presentational aspects.
There are several possible approaches, namely using different view templates / helper snippets, or serving up a different stylesheet. Both have advantages and challenges, and ideally the same visitor would always be served the same version. Results would be fed through a service like Mixpanel.
I fear I may have to roll my own solution here, but would love to hear any suggestions / pointers.
At their root, most A/B javascript testing frameworks cookie a user as being in the "A" or "B" group, give you a way to ask if a user is "A" or "B" and report "results" back to a service to measure. This can plug into Ember or other client-side frameworks in a way that is fairly orthogonal to the framework.
I would recommend exposing the "A"- or "B"-ness of the user as a property on your user (in Ember, probably your UserController). Then you can use your framework's standard branching or conditionals to render the "A" UI or the "B" UI.
I have actually built a pretty robust A/B Testing tool using Ember for my startup. We are actually thinking of open sourcing it if there was a demand for it. I can let you know the basic idea of how it works for now though.
I have landingPage objects, that can then have a bunch of A/B tests associated with the, When a user comes to the landing page, they are assigned a cookie, and for each A/B test that are assigned either A or B.
I have used two different approaches within jade to handle A/B testing.
For styling type things, I use something like this
and set the .css property in the view to either test-a or test-b
or if it is for text I will do something like this
{{view view.landingPageText}}
and the landingPageText would be set to either the text for A or the test for B.
This thing also dynamically sets up mixpanel, mailchimp, and uses parse.com and node. You can see the code in action here.
http://golf.nextstudioapps.com/

Unit testing MVC3 Razor helpers/views without strings

I am trying out the MVC3 Razor view engine, and one the features that I am exploring is the ability to unit test views.
I have seen a number of examples where Razor views can be compiled into an assembly and rendered into a string. The problem is that it renders as a string, so I am left with doing string searches!
Here is what I am trying to do.
Create a Razor helper
Compile helper
Run compiled helper, passing in a ViewModel
Get the output of the helper as some sort of HTML/XML/tree structure
The reason that I want to do this is so that I can test for specific parts of the output. The helper will likely spit out HTML that includes various output gunk. What I want to do is to see if there is a Checkbox with a particular value (for example). If you have seen Selenium tests, it is similar to what I would like to do, except not as server driven tests.
Is there some way to get compiled Razor (or other view engine) views to emit something other than strings?
The short answer is no, because view engines' purpose in life is to spit out strings. Parsing those strings into an XML document is a way to give them a little structure, like #Craig-M suggested. But what you have to ask yourself is what you're really testing. If your view compiles and generates some kind of HTML, there can be three problems with what it generated:
the data it displays is not correct. You would test for this at the controller level, so you can ignore it during view testing.
the MVC framework had an error and it generated the wrong HTML string. You don't worry about this, because MVC has its own test suite and thanks to separation of concerns, it's not your problem.
the HTML has broken the user interface.
That last one would be very nice to test for, but why not test for it in javascript unit tests? Check out popular javascript unit test suites like JsUnit, FireUnit, QUnit, etc. They would all do a much better job than you could do of parsing out Razor output.
I think the value assigned to a checkbox would probably be tested for in Controller testing. But to use your example, testing your checkbox's value could be $('#theCheck').val() == 'the value'. And you can run these against a website running with dependency injected repositories or services to control things like 'the value'.
Just a thought.
One way you could go about this is to parse the html string into an XDocument and have your assembly return it. Then you can query against it with LINQ in your tests.
Edit: I'm trying to figure out a Razor test strategy too. I'd be interested to know how you get the helper to work. So far, I'm drawing a blank in getting them rendered to strings outside of the MVC framework.
How about rendering your views to html and then sending that html to HtmlAgility library? That way you can easily traverse/navigate your html. I don't think there is any way to do that with MVC itself.
It looks like Microsoft has its own answer of how to produce HTML from views, for the purpose of unit testing.