Testing UI, The Humanity...
time to read 2 min | 338 words

I've blogged before on the difficulities of testing an application's UI, but for the last two days I gave it one more try. It should be simple, but the complexities of the UI are dirving me nuts.

I'm giving up, it's too complex to give anything back to me. I find that I spend far more time just writing test than writing code, and the code that I write doesn't push me all that much forward. How do you test for a situation such as:

When creating new project, close all the current project document, unless there are unsaved documents, then you need to ask the user and potentially save the documents or cancel the new project creation.

On this last rule I spent the last two days, trying to express it in a suit of tests that would mean something, and wouldn't be a big pile of code that would break any time I would touch the UI.

I would love to hear from other people about their experiance in testing UI, but I fear that with the current tools, that is just too hard to do properly. My current solution is to divide each form into two parts, one would be the UI itself, and the other one would be the Context class, which I talked about before. That way I can at least test some parts of what the UI do and I would have some seperation between the UI and the controlling code.

Perhaps I could return to this later on and try, but right now it just take too much (bloody) time to do it.

Tweet Share Share 0 comments
Tags: