How Do You TDD UI?


Something I’ve been experimenting with recently is Test-Driven Design (TDD) for user interfaces (UI). In brief (see Wikipedia for further details), with TDD you write a test, run it to be sure it fails, and then write just enough code to make it pass. The power here is that you are forced to specify what should happen before you write the code to make it happen, so you typically write simpler code and less of it.

You can imagine what this would look like using typical UI automation methods: a mess of intricate code that searches for and pokes specific bits of UI. The TDD ideal of tiny tests would be impossible to achieve. Similarly, any refactoring you later want to do (maybe you decide a check box works better than a drop-down list box, say) would be very difficult because you would have to wade through all of your tests looking for the ones that hit the refactored UI, and then figure out how to change them once you find them. This is not exactly agile development!

If you have a Physical Object Model, though, much of this messiness goes away. With a POM in hand you can focus on the UI itself rather than the details of interacting with it. Much of the refactoring you might want to do can be done transparently to your tests. (To continue the example, you just set a value regardless of whether you have a check box or a drop-down list box.) TDD can actually be useful.

If you take things one step further and build a Logical Functional Model you can really take advantage of TDD. The whole point of the LFM is to specify what should happen from your customer’s point of view – which is exactly what makes TDD so helpful. Writing your TDD tests against an LFM gives you complete freedom to muck about with your UI while being confident that you aren’t breaking the intent of your tests.

So TDD for UI can work, but is it useful in practice? I haven’t made up my mind on that yet. But if you give it a try I would love to hear your thoughts!

 

*** Want a fun job on a great team? I need a tester! Interested? Let’s talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.

Comments (1)

  1. It looks like wednesdays are your days to blog…

    I like the idea of TDD for UI, but the application might be a little thin. Since we are trying to move as much code away from the UI as possible, there should be less and less to test. Taking your same example that you continued, if I have objects that are being called from the UI all I need to do is test the setting of a value against each type of underlying object and I can consider it tested.

    Maybe considering it testing layers. TDD is well proven for components and moving as much code there as we can and following your example I wonder at the application of the TDD design against UI.

    It is interesting to play with though.

Skip to main content