Tasty helps test fully assembled web applications in nearly-production environment on real clients as real users.
npm install -g tasty
Tasty supports both multiple and single page applications (with server rendering too) and code coverage. It respects Content Security Policy and SSL/TLS.
Tasty server controls connected clients to run your tests against your application.
Client can emulate real user: navigate, fill forms, check content.
tasty.jsmodule to your assembly or markup.
No. Tasty is intended to run inside browser environment without WebDriver.
The main purposes are:
Tasty gives you only high-level tools to help treat your application as a black box, just like real user does. Interact with text and graphics, not with heartless HTML elements. Try not to use knowledge of your application's markup, assume you're helping a real person to achieve some goals.
Serve your application.
Write a test (this one uses Mocha).
Run Tasty server.
tasty test.js --username 'John Doe' --password 'secret!'
Open your application in your client. Tasty will run the test, print all output and exit.
Either use Tasty from command line or from your code using API.
Tasty can read any configuration fields from JSON file provided by
--config <path/to/config> flag.
tasty --help for more information.
Tasty server is a bridge between the clients and the test runner, it controls each client and runs tests written using Tasty tools.
--url flag to configre server's own URL.
Tasty supports any test frameworks that support asynchronous tests.
Check out the API available for tests.
--watch flag to watch for changes or run on several clients.
Tasty client is a small extendable UMD module that connects to the server and executes its commands.
It has its own API and isolated polyfills for non-supporting browsers.
tasty.min.js if you don't need to debug your tests.
You can run built-in static server on the same URL by passing
--static <path/to/root> flag.
--static-index flag for SPAs and add
--embed flag to inject Client automatically.
For Tasty server running on
localhost:8765/path you should add the following CSP directives for Tasty client to work properly:
connect-src ws://localhost:8765/path script-src localhost:8765/path
wss if you serve from HTTPS.
Tasty's static server automatically injects that directive into HTML files when
--coverage <name> flag is used.
Remember, CSP allows consequently applied directives to only restrict the resulting set, i.e. meta tags can't expand/loose header directives and vice versa.
Check out a great tool for generating and validating CSP directives.
Currently Tasty can't find text
+1 123 456-78-90 in the following case:
In other words, it's too hard to join text fragments of
Also, search cannot detect text from
alt attribute yet.
Border images are currently skipped.
<object /> and
<embed /> are not supported out-of-the-box.
When using auto-focus elements (such as
<input />), you could encounter
cannot type into active node <body /> error when window loses its focus, which causes
paste tools to fail.
If you don't want to focus such elements explicitly (using
click or something else), make sure that client window remain focused during tests.
For WebDriver clients you could maximize window or use
alert() workaround to focus reliably.
Additionally, Chrome DevTools could force current tab to lose focus, with the same results.
Remember, you can always click on something to reset autofocus when you don't need to test it.
Not supported yet.
Some elements of browser itself, such as tooltips from
title attribute or HTML5 Form validation messages, could be potentially detected, but currently aren't supported.
The lambda above will be called on the client "as is", so if it doesn't support arrow functions, the call will fail. It's more safe to always use
function literals in such cases.
Tasty console output could be wrong or confusing if
window.console is modified by your application. If this is the case, make sure Tasty client code is runnig prior to application code.
Not supported yet.
Each tool adds corresponding action to the runner queue instead of performing that action immediately. This allows to write tests in synchronous manner.
Queue is executed after
now() call without arguments, which returns
Your testing framework may prefer callback for async tests.
For testing SPA (or rich MPA) you can provide a method for Tasty to ensure that client is ready for the next action.
The simpliest way is to just wait before or after using some tools.
You may override the list of tools to wait before and after.
You always can manually add a delay into queue.
There could be enough to just check if DOM is ready...
; // 'DOMContentLoaded' aka 'interactive' readyState
; // 'load' aka 'complete' readyState
...and maybe wait a little bit.
Another way is to provide some application-specific code.
Call without arguments simply executes
ready logic, which is useful in some cases.
Note that ready methods cannot be combined.
now(...) call with function(s) allows you to add some custom logic into test, but you should use
now.* namespace for tools.
now.smth() is the same as just
smth(), but runs immediately. You should use
now.* tools inside
now(...) call if you don't want to break execution order.
Some tools, like
until(), accepts functions that will be already queued, so feel free to use
now.smth() from them.
On staging or other near-production environment, Tasty can't pass (re)CAPTCHA or two-factor authentication for you.
Store passwords in your Continuous Integration tool and pass credentials into command line. All arguments will be available in
If you're automatically taking screenshots or recording videos during test run, they could potentially contain passwords (e.g. typed into wrong fields because of error) or other sensitive data.
Also, Tasty logs all typed/pasted text into browser console.
Get two-factor nonces from backdoor or use paid services to mock real mobile phones.
Use reCAPTCHA testing
secret for testing environment.
Instead of trying to click on iframed content, simply fake reCAPTCHA response with some suitable string, e.g.
secret, reCAPTCHA server should accept the same
g-recaptcha-response unlimited number of times.
If example above doesn't work (e.g. response format is changed), get new fake
<textarea name="g-recaptcha-response" />on the page.
For other CAPTCHA implementations, get answers from backdoor.
Do not use production certificates with Tasty: server is not intended to be accessible from external networks.
Use Let's encrypt, self-signed non-CA certificates or set up your own CA.
npm run prepublish
npm run support
Everything works fine, yay!