3

Currently I'm using a combination of specflow, selenium, fluent automation and xunit to test my browser application on a deployed instance of the website in chrome. This works well on a developer machine but frequently fails on the build server agents for no apparent reason other than the build server agents are slow.

I've been all over the phantom.js documentation I'm struggling to understand if I can use phantom.js to test my application fully.

My application has a lot of javascript logic, I use requirejs to load all my modules and I'm wondering if I can use phantom's headless browser functionality to test all the functionality of it. Will it download all the javascript files and then allow me to do actions on the dom like launching modals that have forms in them? Lots of the UI is built with knockout templating.

I've done a few searches but nothing definitive has come up. Does anyone have any advice on this? I'm not so bothered about cross browser testing at this point, we've got manual QA for that. This would just be for a happy-path early warning system of functionality failing through ui-automation of all the user stories.

At the end of all this I made a couple of changes which were really useful

  • Accessing the selenium driver and checking for jQuery.active
  • Creating a new expectOne/assertOne which throws if the css selector returns more than one item for a selector
Neil
  • 5,179
  • 8
  • 48
  • 87
  • 1
    Any detail you could provide on the issues you've had with FluentAutomation on your build agents would be great. I'd love to look into it and try to help. Most of the time the issue has to do with browsers not being started/cleaned up or the tests not being run in a UI session which can cause some issues. – stirno Nov 27 '13 at 17:17

2 Answers2

7

PhantomJs is a complete browser implementation that just doesn't render to the screen (it does have a buffer that can be captured via screenshot though). If manual testing covers the preferred browsers and you just need to know hard failures, give it a shot!

FluentAutomation.SeleniumWebDriver supports PhantomJs out of the box in current versions. Just choose PhantomJs as your 'browser' and it'll work. The FluentAutomation.PhantomJs provider is deprecated and will go away.

FluentAutomation.SeleniumWebDriver.Bootstrap(FluentAutomation.SeleniumWebDriver.Browser.PhantomJs);
stirno
  • 598
  • 4
  • 10
3

Yes.

You might find CasperJS more useful for testing. The built-in tester module is quite easy to use. Casper also opens up using SlimerJS (for Gecko/Firefox testing) with no additional code needed.

In either Phantom or Casper You can use page.evaluate() to run any client-side JavaScript, so that should be no problem.

Darren Cook
  • 27,837
  • 13
  • 117
  • 217
  • We use phantomjs/casperjs to run some tests on our js-application every morning. We simulate complex workflows and take screenshots after every step. So we can see what went wrong. BUT 2 things: 1. You have to code every step - thats not a typical QA-task and 2. It is no replacement for unit tests - but unit tests can run in phantomjs either; see chutzpah... – Andreas Dec 02 '13 at 14:27
  • @Andreas Agree on both points. To make it easier to create tests you can use FireBug. E.g. the CSS selector for this very comment bar I'm typing in is `html body.question-page div.container div#content div div#mainbar div#answers div#answer-20261132.answer table tbody tr td div#comments-20261132.comments table tfoot tr td.comment-form form#add-comment-20261132 table tbody tr td textarea` !! – Darren Cook Dec 03 '13 at 00:15
  • Given that he's already using Fluent Automation which encapsulates PhantomJS @Stirno's answer is probably the way to go. This would require re-writing his entire test suite, whereas stirno's answer is a one line change. – pauljz Dec 03 '13 at 00:24
  • 1
    @pauljz I kind of agree. I decided to post because the OP said "we're using this stack and it doesn't work properly for a reason we don't know". Using CasperJs allows you to use a different technology, to narrow down if the current stack is the problem. It also allows you to swap in SlimerJS (i.e. Gecko), to see if the webkit engine is the problem. But I'd definitely try stimo's one line change first! – Darren Cook Dec 03 '13 at 01:02