bfulop / interactive_frontend_dev Goto Github PK

Related to #4 and #1

The idea is to delegate all browser-related actions (testing) to WebdriverIO, while keeping Wallaby as a focused test runner.
The main issue with an Electron/Wallaby based browser testing is that the solution to resize the browser window is a bit hacky.

Hopefully WebdriverIO will bring more robust browser testing capabilities. Also, this strategy will hopefully make it easier to run the tests on a wide variety of browsers through Selenium.

Getting error this.posX is not defined.

In the most urgent use case, we need to do two things with this tool:

1. BDD workflow for writing HTML components
2. Export components to be used in a Symfony backend

In both cases the components data can come from the file system. This is solved.

Sometimes (more rarely) we do need to add live components to a page. For example a list should update it's content. This is still not an SPA, so we don't need routing. We just need that the dispatch function updates the model and rerenders.

The realistic use case will be to have several independent components rendered on the page. Plan out the architecture, how they should be managed.

#16 #17

When there are several tests Wallaby runs them in parallel. In our case, this means it opens more than one browser window. When doing live editing and testing, Wallaby will most likely only use worker id 0 to update the browser.

This is to help find the browser window when doing live editing.

For testing and style guide page generation the api can get their models from the file system.
When the components will be running in the browser the data will be coming from either an AJAX call or another module.

Account for this in api.js module.

#16

WebdriverIO can take advantage of the PageObject pattern to simplify writing the assertions.

Render into files and CSS with Inferno server and Aphrodite

The goal is that the component under test is being rendered in the browser on each edit with WebdriverIO.
The component is a JavaScript file function and I want to use Inferno in the browser to update the HTML.

Related to #5 and #1

The before hook does some setup on the browser ("arrange"). Usually, it updates the component in the browser. This should happen on all "browser sizes" i.e. all nightmarejs instances.

#14

Save some default texts, images, etc (model) with the same filename as the component with a suffix.

Load this with through api.js and in the tests as well.

#1

The goal is to test the layout at different screen sizes

Related to #1

Wallaby will launch several workers when you have lots of tests and runs them in parallel. After it will mostly use the first worker to do the interactive testing.
So all other workers don't need to actually open the electron window and can close after the tests have run.

With WebdriverIO Multiremote it should be possible to open several browsers at different screen sizes and test them in parallel.

This is for unit testing the responsive layouts.

Related to Resize Electron window inside the tests? in WallabyJS discussions repo.

Related issue: #1

Ideally, we should see tests failing or passing when saving either the spec file or a component file.
This should be as fast as possible, so the browser should keep the window open, keep the page open and detect which component or spec file has changed and run only the minimum of tests needed.

A. Webdriver testrunner --watch mode

Webdriverio has its own test runner (using Mocha) that supports file watching by specifying the spec files in its config files. It seems quite fast, it doesn't reinitialise the browser, reloads the page etc.

Need to test if I can add non spec definitions to the spec list in config.

B. Using PhantomJS

Check if possible to use assertions (element relative position on page, etc) with PhantomJS

C. Webdriverio stand alone mode

Include webdriverio as a library in Mocha tests and set up watching manually (avoiding to rerun the complete suite).

D. Doing atomic renderings and running assertions with WallabyJS

Render the component in a before() hook in Mocha and using Electron then run the assertions.

This is for live unit testing. Related to #6, #5 and #1

The CSS lives in the JavaScript component as an object so it can be passed by WebdriverIO as a function or JSON and rendered on the client. This has to be synchronised with #5 as the CSS classes are being dynamically generated by Aphrodite. The className is a hash of the CSS rules.

Replace sub components (testdouble.js ?)

Instead of rendering the sub component, render a placeholder component

related to #1

Let the user define in one place a list of target browser sizes he wants to test and the helpers should do all the necessary setup.

Related to #1

The current setup using WebdriverIO and Selenium works really well and the performance is great so far.

NightmareJS would probably even more performant when doing interactive testing with Wallaby. The fact that we're already using the PageObjects pattern should allow us to swap out the WebdriverIO to NigthmareJS. Then, we can still use the WeddriverIO test runner for running tests on a cloud service, or locally on several devices.

Will try this.

During live testing, at each keystroke aphrodite adds a new CSS definition to <styles>.

Old styles could be removed, but it has to be done through Inferno. If I revert the state of my CSS Aphrodite/Inferno will not add a new element but reuses the old style. So this has to be done with care...

The idea is that the test definitions should be the same wether running on NightmareJS or WebdriverIO.

Part of #14

The goal is that the layout unit test would also run in a cross browser testing platform (Browserstack, Saucelabs, Crossbrowsertesting, Testingbot), separately from the Wallaby interactive test runner.

• add environment variables to toggle parts of the test related to Wallaby/Mocha
• name the test files that should be run on the testing service (not business logic unit tests)