I've been developing a Rails application and I've decided to implement a mixture of Test Driven Development and Behavioral Driven Development.
However the application I am building uses a web application user interface framework known as MochaUI which is built on top of the Mootools framework.
I have just finished writing a portion of unit tests and have moved on to testing the user interface; which is where I start to run into problems.
A lot of the things I want to test is content that is loaded via javascript, some data is loaded into iframes, some data is loaded into elements (ajax).
So I wrote a test
And I should see "Some text loaded into an iframe with javascript"
And as you guessed, it failed. I don't know where to begin to fix this problem, as I am very new to TDD and BDD but I'm working my way there, can anyone give me some pointers or possibly a solution so I can sleep at night?
Thanks!
There is selenium for javascript-testing... Maybe this would be a tip?
see http://github.com/aslakhellesoy/cucumber/wiki/Setting-up-Selenium
or
http://bddcasts.com/series/tools/episodes/using-selenium-with-webrat-and-cucumber
Use capybara, tagging the scenarios that require javascript with #javascript.
Related
I often compile informal datasets by running some kind of XPath/XQuery on publicly available web pages. Usually the structure of the HTML is regular enough that useful information can be extracted easily.
But today I've come across tunefind.com. This website makes extensive use of the REACTJS framework, and so most of the structure of the page is configured client-side by Javascript. The pages, when initially downloaded, are very basic and missing a lot of information. The pages are populated by a script that uses a hopelessly messy blob of JSON data at the bottom of the page.
The only way I can think of to deal with this would be to use some kind of GUI-based web engine and just not display the GUI part. But that is a preposterous amount of work for these casual little CLI tools that I use to gather information.
Is there any way to perform the javascript preprocessing without dealing with unnecessary graphics?
Even if you were to process without the graphics the react javascript will be geared towards running in a browser context, at the very least it will expect a functioning DOM to exist, the application itself may also require clicks / transitions to happen before you can see some data.
Your best bet then is to load the page in a browser, to keep this simple, there are plenty of good browser automation frameworks designed for this.
I've used a fair few libraries over the years including phantomJS and recently I've gotten the most mileage out of nightmarejs.
It runs an electron browser for you and gives you a useful promisified javascript API to control it with, that has common browser functions such as clicking, following links etc.
You can configure it to hide the browser which is useful for making a CLI tool, however its a bit of a pseudo-headless mode and will still require a windowing/graphical context (e.g. x window).
Hope this helps.
PS - If you're at all used to docker it's not hard to make this just a running container!
I want a javascript framework which has features like below:
MV*
Well structured
Html file as template
Rendering fast(maybe virtual dom?)
Combine and compatible with other plugins or libraries
Edit on tablet IDE apps and view in browser immediately by refreshing page after I changed code
When I am at home, I use PC to develop my client-side(or front-end) applications.
When go out, I use my tablet(I have no note PC), so I want to develop my applications outside.
*There are some excellent IDE apps on the Android Market.
Before I know Ember, I have been using pure javascript(jquery) + css + html to develop client-side application for daily practices or work.
But recently, when I began to learn EmberJS, a Javascript MVC framwork, I am lost.
It seems that EmberJS have to get its own server up to compile something, which generate static contents for browser rendering.
I just want to get my client-side code(files) rendering in the browser, but why I have to 'run' it as if I get apache started to serve as a php back-end.
I have googled hundreds of pages to find a solution, nothing expected result discovered.
Including Angular, backbone or any other popular Javascript MV* frameworks, they all must compile there applications.
Is there anyone who has encountered this situation?
Then any advice, please?
Increasingly most Javascript frameworks are shifting to doing a "compile step" as part of using them. This allows you to do a variety of changes to your Javascript files, which in turn makes it easier for you as a developer. An example of this is that you can use ES2015 classes and then have your compile step "transpile" them to older Javascript that will work in all browsers.
The side effect of this though is that you need to have npm running on your computer to be able to do this well.
If you really don't want to have the compile step, then I would suggest looking at VueJS. It's the only recent Javascript framework that allows working with simple non-compiled JS files. But you'all be missing out on some of the best changes to Javascript as a result (ES2015 has made life much better)
Finally, I found a nice solution(framework) that is Durandal.
Really, pure HTML+Javascript without built and server up(anyhow, a web server needed if I wanted to publish it in my hosted web server).
.html extension and designer friendly.
I can upload its source files directly in to S3 and browse the html pages.
Just found some nice examples with well structured project on github is here.
And I can work smoothly with my dear designer friends.
Though its next generation Aurelia will also be built and serve it up like Ember or others, but the current generation is enough for me.
Hope those one got help from this;)
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)
I'm writing an automation program for a Web Application. I am accessing the Web Application through a javascript API and have wrapper functions with custom assertions that currently just write output to a table in an HTML page.
Now I need to get the data output into my hudson (https://hudson.dev.java.net/) automation, where I have a lot of flexibility when it comes to arranging, sharing and presenting the results.
When I wrote NUnit tests, the hudson-integration was impeccable. I saw there was a thing called JSUnit, but it is no longer actively maintained(?), so maybe I shouldn't spend too much time learning it?
I have seen that tools like Firebug can output javascript results to a console, though I don't know where to go from there. The console output seems to stay in firefox and come no further.
Any help or tips are most welcome.
Thanks!
/ Jakob
If I understand correctly, you want your Hudson build to run a test of your Web Application which is set up and running somewhere else. (This gets a little harder if you're also building your Web Application and want to set it up for a test run all inside Hudson.)
The easy option: As one of your build steps, retrieve the HTML page with your output and tell Hudson that the page is a build artifact. That way you can look at the test output manually.
Somewhat harder: change your test output (or pass a parameter to specify the format) to match the XML format used by NUnit -- see example XML output. This is a direct link to an XML file and may not display well in your browser; try viewing source or saving as text.
Update: On re-reading your question, it wasn't clear to me whether you were interested solely in Hudson integration (which my original answer assumed), or in other possibilities for testing frameworks.
Depending on what you want to test:
you might look at testing your Web Application with Selenium. I know there's a Hudson plugin for Selenium, but I've also noticed several questions here recently describing problems with Selenium+Hudson. I don't have any experience with the combination myself.
there are lots of javascript testing frameworks with different capabilities.
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