Sai wrote:

> I have been thinking about the points which affect UI testability for
> sometime. When it comes to unit testing there are specific points like
> Dependency Injection, usage of Singletons as factors which affect it.
>
> Similarly it must be possible to get a set of points which we must be
> able to do or avoid to help UI testability. I need your help in
> collecting these points so that it will help us while we think about
> design for testability at UI level.
>
> Some points to get started
>
> 1) Building custom controls like grids or tables either from scratch
> or from available controls. Sometimes I have seen people drawing their
> own controls which makes testing extremely difficult

If you are using an off-the-shelf control, such as an edit field, you can TDD it
by building its form, running production code to push data into it, then
querying the data out with the control's accessor methods. I am only talking
about TDDing from inside the same language and platform as that form - not
external UI testing.

If you invent a custom grid, or if you override the hooks in a standard control
to write your own special effects, then you must TDD the new art and input
itself. You can do that by intercepting your graphical paint methods at a level
equivalent to Gdk or Cairo. Then tests can query the paint methods back and
determine they are correct. You TDD the inputs by putting trace statements
inside your input handlers that reflect input events, then click or type on the
control, and convert the trace output into sample inputs for your test case.

Once the control works, then you can trust its accessor methods, and the
business-level TDD can access your data the same as with a standard control.

> 2) Auto generation of UI code. Most of the time it leaves us with
> randomly generated locators

The best thing about auto generation is you are not TDDing your generator
itself. So if you can TDD the script that you send into the generator, then your
unit tests save a lot of labor and noise by not generating at all.

We do this all the time in Rails, with that ubiquitous and infamous IU
generator, XHTML. Test-side parsers, such as .has_xpath or .has_selector
(meaning a CSS selector), or assert_xpath, are really tests that...

- render the generating script from production code
- parse the script (and assert it parses correctly)
- drill down into its contents to isolate one context
- TDD that business logic deposited the correct data inside that context
- not feed the script into the generator (your browser)

So any generator script you use, you gotta get (or write) a parser script for
it.

> 3) Not using normal locators like id, name which makes testing complex.

There are situations where that does not work.

However, almost all of our TDD in Rails Views depends on...

- generate a unique id for each container
- use assert_xpath{ with a block } to isolate that container
- use assert_xpath inside that block to detect logical data

All these assertions intend to provide the clearest possible assertions at fault
time. Constraining those blocks like that lets their fault diagnostics reflect
only their inner context. When an assertion fails, it does not spew out an
entire page! I don't know why, but other XPath test assertions don't let you use
a block to constrain your context...

> 4) Using technologies which don't have testability in built like Javafx.

We must come to a point, as an industry, where we start rejecting technologies
that can't be tested.

Until then, any port in a storm. I test JavaScript the same as XHTML - by
parsing it into a lite database, and then querying the database to detect
logical data. If, for example, the JavaScript is an Ajax response containing
JavaScript to update a DOM object and push in new XHTML content, I parse down to
that string, evaluate it, and stick it into the current XHTML context. Then
subsequent assert_xpath calls can detect important fields in the content.

Nobody else in the industry does this, and I don't know why...

> 5) Highly asynchronous process.

If you suspect a process might need threads, try as hard as possible to avoid
them. Invent your process, via TDD, without asynchronicity. Build your algorithm
to use time slicing, and TDD both the individual time slices and their gestalt.
This forces your code to have the kind of good structure it will need if you
then must make it asynchronous.

Call your time slices from a dispatcher, such as your windows's Timer event. If
the process does not work like this, only then should you move the dispatching
into a thread.

> Please let me know about your thoughts and challenges you faced in UI
> testability.

I intend to blog up a complete dissertation on each of these things. Quite
frankly, the biggest challenge for me has been trying to help the industry make
TDD for GUIs as easy as it is for me and my teams.

--
Phlip