Women in Technology

Hear us Roar

  Agile User Interface Development
Subject:   I'm sorry....
Date:   2004-11-18 02:11:31
From:   AndyP
In this article you suggest putting functionality into a separate class (lets call this class a 'model'), and having all the display code in another class (the 'view'). You then apply TDD to the model.

Maybe I don't get this but surely suggesting the use of MVC is blindingly obvious. I also think that only testing the model, defeats the entire purpose of testing a GUI. It's realtively easy to test the model in isolation. How does your glorious TDD try to test for all the strange and unpredictable ways that users click on buttons in a GUI? GUI's are event driven, and typically multi-threaded. And all this in the view code which you suggest we shouldn't test.

Please help me to understand what you are trying to say becuase from my naive viewpoint it just seems to be, 'use MVC patterns, and only test the model'.

Full Threads Oldest First

Showing messages 1 through 6 of 6.

  • I'm sorry....
    2004-11-18 06:47:17  b.j. [View]

    I agree with AndyP entirely.

    A better example may be to find a test tool that can test gui interactions. HTTP::Recorder and PAMIE are examples of such tools for testing web applications.
    • I'm sorry....
      2004-11-26 11:00:35  decoder [View]

      Gotta disagree here fellas. I totally agree w/your critique; this article has no useful new information and is incredibly naive. And I totally agree that there are things in the view that absolutely must be tested for. What I disagree about is that you have to go straight to a scripted integration testing tool from this decidedly simplistic 'test the model' approach. In fact, the Gamma/Beck book Contributing to Eclipse has a lot of excellent examples of writing UI unit tests. Unfortunately, that is using a framework that is not really hosted like web frameworks are. Even the new Manning book on JUnit Recipes punts on this one. Someone needs to do much more work on this and I tend to blame the framework developers. Why doesn't JSP and JSF come with a simple way to do unit tests? All they would need to do is make it very simple to compile a page (without having to run the whole container) and/or mock it completely.
      • I'm sorry....
        2004-12-03 19:29:29  jbrains [View]

        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?
        • I'm sorry....
          2004-12-06 09:05:42  decoder [View]

          Actually, I didn't explain that point well enough. If you read that whole section of the recipes book, it starts by saying that most people think that most people think it's not worth the effort, but then, ultimately, because Jasper won't compile pages for them, they just walk away. The very next section is about Velocity and how simple it is to test templates there.

          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.
          • I'm sorry....
            2005-02-02 17:27:38  jbrains [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.
      • Testing JSPs etc.
        2004-11-29 06:55:26  ipreuss [View]

        You can compile a page using the ServletRunner of ServletUnit (which is part of HttpUnit), a very lightweight servlet container for testing purposes (it doesn't even implement the http protocol).