| Article: |
Agile User Interface Development | |
| Subject: | I'm sorry.... | |
| Date: | 2004-12-03 19:29:29 | |
| From: | jbrains | |
|
Response to: I'm sorry....
|
||
|
I don't understand how JUnit Recipes "punts" on this issue. It includes a collection of recipes related to testing web user interfaces /in isolation/ -- something that a majority of even the TDD community claims is not worth the effort. I have test-driven web UIs implemented with Velocity with relative ease and to stunning effect, and included that experience in the book. What more are you expecting? |
||
Showing messages 1 through 2 of 2.
-
I'm sorry....
2004-12-06 09:05:42 decoder [Reply | View]
-
I'm sorry....
2005-02-02 17:27:38 jbrains [Reply | View]
It is pretty difficult for me /not/ to have read that whole section of the book. I read it while I was writing it. :)
As for JSPs, it is still impossible to test JSPs entirely outside the container, and as a result, I prefer to use other page template technologies. That said, it's easy to write tests for JSPs using Cactus, something both JUnit Recipes and JUnit in Action describe in detail. Because Vince did such a good job writing about it, I didn't feel it necessary to try to do any better.
I really don't understand this comment: "[T]heir whole 'gold master' approach is super simplistic and not given much serious treatment." In what way didn't I treat it seriously? I use it seriously often enough. What wasn't serious about it?
I admit I'm no expert on JSF, so I can't comment on how to test JSF-based applications. If I ever find myself on a project using JSF, then I'll learn what I need to learn and I'll probably write about it.
I really liked your closing comment: "Most people think of unit tests as being simply so we can figure out if something works. Automation yields a much broader value: being able to know that something works at all times." I couldn't agree more.





Furthermore, their whole 'gold master' approach is super simplistic and not given much serious treatment.
Let me be super-specific. In JSF, the framework kicks back messages automatically if a validation or conversion fails. I made my own custom component to pick up those messages and turn the style of the corresponding field's label to red text. Wouldn't it be great to have a unit test that creates a form, forces an error and then checks to see that the style of the label in the response (the same page being redrawn) was red?
Most people think of unit tests as being simply so we can figure out if something works. Automation yields a much broader value: being able to know that something works at all times.