On Tuesday, August 27, I shall be presenting a webinar on our new functional testing tool for the web, TestCafé. Supporting me will be members of the team that created the product and we’ll be providing as many answers as we can in the half-hour or so of the presentation. I shall of course be demonstrating TestCafé in action; sometimes a picture (or a video) is definitely worth a thousand words.
In preparation for that, let me provide some answers to some questions about the product. I dare say I’ll be talking more about these topics during the webinar, but it doesn’t hurt to provide some foundation first. So, without further ado, here’s the Top Ten questions.
Q1. What is TestCafé?
A. It is a tool, a system for creating and running functional tests for web pages, sites, or applications. As I’ve put it before, if it’s HTML5/CSS/JS and served up by a supported browser, TestCafé can test it.
Q2. What is functional testing?
A. Functional testing is a QA process designed to test what a system does, and not how it does it. (The latter is more the purview of unit testing.) In other words, you the developer (or tester) define what should happen in a certain scenario with certain inputs, and functional testing verifies that the output is as you’ve specified. Let’s take a small common example from a blog: each article in the blog is shortened in the browser and has a “read more” link. When the user clicks on one of those links (the first, say) the page should slide down to show the remainder of the article. A functional test would recreate the initial conditions, “click” the first link, and then verify that the resulting page has the article visible.
Q3. Does it work on WinForms/WPF/Silverlight/Metro apps?
A. No. This is a web testing tool. Think “testing HTML in a browser” and you can’t go far wrong.
Q4. You mentioned ‘supported browsers’. Which ones?
A. Essentially any browser that is capable of rendering HTML5 and that supports a modern dialect of JavaScript. So, IE9+, Chrome, Firefox, Safari, Opera on Windows, Safari and others on the Mac, browsers on Linux.
Q5. They’re all on the desktop, but we need to test our mobile web pages. Does it work with browsers not on the desktop or do we have to use a simulator?
A. Yes, TestCafé works with any device with a modern browser. So, Safari on the iPhone or iPad is supported, as is the Android browser and IE on Windows Phone 8. Using simulators for testing? <spit>
Q6. Wow, does that mean you provide plug-ins for all those browsers as part of TestCafé?
A. No, we don’t. The reason is that, unlike other web testing tools, TestCafé does not use plug-ins at all. When we were coming up with the idea for TestCafé, we recognized that a plug-in architecture was fundamentally flawed. Plug-in functionality is restricted by the browser manufacturers, and yet a testing plug-in has to somehow replicate user input gestures (keyboard, mouse, touch), screenscrape in some way to verify output, read the DOM of the page, verify whether page elements are visible or not, and so on. In essence, the problem is the plug-in is manipulating your browser, not the web page; there’s an awkward man in the middle.
So, no hunting for that plug-in for Firefox 20 or the one for IE9 so you can install it. There is nothing to install in the browser under test. Zip. Nada. Zilch.
Q7. So how does it work? Surely it has to replicate user actions in order to run tests, and that would require a plug-in to feed keystrokes or mouse actions.
A. Not at all. And herein lies the beauty of the TestCafé experience. There are two main parts to TestCafé: the server and the client library. There’s the server part which holds the dashboard and analysis components (as well as the proxy server) that launch the tests being run on the client (one or more browser instances on whatever devices). This part runs on node.js, with the Control Panel being viewed inside a browser. Then there’s the client-side library that runs the tests within the client browser and communicates the results back to the server. The clever bit is that the client browser loads its pages through the TestCafé proxy server, which means TestCafé can inject the client-side library inside the page being tested.
Now, both the server and the client could be run on the same machine (this is how I do all my work with TestCafé), but they don’t have to be. The client browser could equally well be on a remote PC or mobile device connected to the LAN. All you have to do in that case, is to ‘register’ the remote browser as a ‘worker’ with the TestCafé server by navigating to a special URL, after which TestCafé does the rest. Oh, and just because I use the term ‘client’ in the singular doesn’t mean that TestCafé is somehow restricted. It can run tests on many browsers simultaneously in parallel. And when we release a new version, all you have to do is update the node.js server, you don’t have to go to every single browser you’ve used and update those: the TestCafé server is king.
Q8. How do you create a test in the first place?
A. Two ways: you can get TestCafé to record it for you, or you can write it from scratch.
Q9. Great, so there’s yet another DSL (Domain-specific language) to learn?
A. Nope. All tests for TestCafé are written in JavaScript, even the ones recorded by the tool. If you think about it, that’s the only way it would all work: the client-side library gets your tests as JavaScript files and just executes them. You can put anything in your tests, including calls to your own libraries that you’re loading as part of the page. In other words, code re-use is other big benefit of using TestCafé. The biggest benefit of all though is that your test code is running as part of the page in the browser. You have full access to the DOM of the page; it’s just as if your tests were part of the page. There is a small TestCafé API to learn, certainly, but it’s not a completely new language.
And that, boiled down to the basics, is why TestCafé works on all devices with a modern browser: it’s just JavaScript all the way down. If you’re a web developer, you know it already and TestCafé fits right in to your experience and workflow. If you’re not a web developer or tester, why are you reading this?
Q10. How do we get TestCafé? Is it a service or is it a separate download that we install?
A. It’s a download. Yes, we could have launched TestCafé in such a manner that we controlled the server part (in essence, we could have “rented” out testing services), but we recognized that a lot of web testing is done in a QA environment which may be just running on an intranet, with no connection to the internet. In that scenario, it makes sense to provide the server part as part of the TestCafé install.
You can download TestCafé right now for non-commercial purposes. So if you want to try it out, go ahead, download and install into a local instance of node.js and experiment to your heart’s content. If you want some hand-holding as you set it all up, please visit our documentation page: there’s a full tutorial of how to configure TestCafé, how to create tests, how to run them and debug them, and how to add them to a Continuous Integration system. Or just watch the supplied videos on those tutorial pages. Or, if you’re like me, do both ;). Of course, full support is also available from our support team if you get stuck.
If you want to use it for a commercial site or app, we sell licenses per developer/tester, not per machine. You can buy a license for $499, and please note that we do have discounts for multiple licenses. Naturally, you get all the benefits that the non-commercial tester gets, with the additional benefit of faster response to support questions.
So, see you on Tuesday, August 29. Register now!