Loading ...
Sorry, an error occurred while loading the content.

Re: JBehave's examples

Expand Messages
  • rett
    Elizabeth, Before I start into analysis, let me say that I do like the documentation technique and the naming conventions are lovely, though all the dross that
    Message 1 of 154 , Apr 30, 2007

      Before I start into analysis, let me say that I do like the documentation
      technique and the naming conventions are lovely, though all the dross
      that the language hangs around it somewhat negates that, but that is
      a problem with most language tools, object oriented or otherwise.

      Thank you for filling in the spaces for me. I'd love to have customers who
      both could and would write the stories and scenarios. They are certainly
      the ones with the knowledge and the need. If they can be given some help
      and training in breaking down things into a sufficiently fine grain, it
      is even
      possible.I still do not believe that there is any substitute for having
      spend a bit of quality time in the environments for which they will be
      In this case, that would probably be fairly trivial, in that they would
      only need
      to use a PC keyboard for some form of interactive game play, but there is a
      lot of subtle action in working environments that have been customized
      around a process for making some product, whether it be paperwork or
      manufacturing or legacy system or systems.

      If there were a display of state after each movement, then you would have
      a movie of the play that could be examined frame by frame, or played as a
      full demo of whatever piece of code is being tested. The display at the
      of the piece of code that was included was hard coded. I'll assume that
      wasn't the case in the full test code, because I doubt that "verb"
      oriented game
      play will tell me too much about most of the business code with which I
      been involved. But, it is interesting in and of itself.

      "For interest, here's the code for 'The player presses
      right rotate', and the relevant snip from HellboundEvent :"

      There is no indication of whether this is sensitive to
      machine state, such as caps lock or other modifier and if
      you are trying to write this with abstraction on the key
      assignment, you would want to maintain "x" and "y" as
      state sets of some left and right rotate key objects, rather
      high in the hierarchy or as external inputs from some "main"
      or even the user. I'm also having a bit of trouble with the
      timeout exception that is being thrown. Most Tetris style
      games would have no such timeout. They just keep generating
      and dropping objects whether the player does anything or
      not. Maybe that is just a defense against unpredicted
      lack of return from the routine.

      Now, if I were going to perform something that resembled a
      valid test, I would generate a wrapper that provides the
      user input to the program through the interface that the
      program uses to receive that input, or as much of that as
      I can get. I would want that interface to allow me to
      generate those inputs with varying timings between key
      presses and with other key press information coming in at
      random intervals. I'd also want to be able to test
      those timings with randomly generated delays in both input
      and display relative to real time to see how those affected
      the validity of perceived game performance. The ultimate
      test would be high frame rate videos of actual play, since
      games are quintessentially real time. This is another one
      of those cases, where the game logic is fairly trivial when
      you are simply programming the process, but where
      externalities can have huge effects.

      Of course, this is JAVA, and most of those interfaces are
      not available to the JAVA programmer, which means that any
      game more complex in input and display than Tetris/Hellhound,
      probably is not a good candidate for being written in JAVA.
      The success of such a project is going to be a lot more
      dependent on the choice of tools than it is on the program
      logic. Real time programs require real time testing tools.

      Let us take that a bit further. Any program that requires
      significant data input from the user has to have a viable
      set of stories for the external acquisition and handling
      of that data to go with the stories for the handling of that
      data once it is in the computer. So, if a piece of data is
      not going to be available or not available on a timely basis,
      the program must account for that. That is where it is
      absolutely essential that the customer write stories and
      scenarios and that the programmer understand which parts of
      those must remain external to the program.

      Everett L.(Rett) Williams II

      Elizabeth Keogh wrote:
      > rett wrote on 28/04/2007 10:39:26:
      >> Showing the customer this is not going
      >> to give
      >> them one whit more information about how things function than they would
      >> have had after reading the story.
      > Hi Rett,
      > We try to make the customers write the stories and scenarios in the first
      > place. You can see the English versions at:
      > http://svn.codehaus.org/jbehave/trunk/examples/hellbound/src/stories/
      > The java code was taken directly from this.
      > I admit to being my own customer in this case; I picked Tetris because the
      > functionality's already well understood, so I could write scenarios
      > without feeling that I was being easy on myself. Word on the ground is
      > that this approach is easy for real customers to pick up too (and has
      > additional value for them as it helps clarify what they want and makes it
      > easy to spot missing scenarios or stories).
      >> I do understand what objects and methods are, and I understand what they
      >> are supposed to do, but this example seems to involve game play rather
      >> than game programming, with a final display of accumulated state. Is
      > this
      >> out of some demo or automatic play.
      > The code I posted forms part of an executable story (or 'acceptance test'
      > for TDDers). There are two ways to run stories; with the StoryPrinter
      > (which turns it to plain English) or the StoryRunner (which executes and
      > verifies each scenario - it runs using Swing). The story class is passed
      > in as an argument. Please note that I've posted the scenarios here because
      > they're most interesting; the stories contain the scenarios.
      > I guess if you wanted to slow the scenarios down it would be a demo. If
      > you want to see it in action, again - check out JBehave's code, cd to the
      > trunk directory (or just checkout trunk, of course!) and do
      > ant run-example-stories
      > You should see the Swing harness in action. Watch carefully, as it's
      > pretty quick. You will see the pit flicker in and out of existence, and
      > the shapes move and drop and change. (It doesn't always work in Linux due
      > to bugs in Swing event handling, but it breaks nicely when that happens.)
      > You will of course need to have ant and java installed, and on your path.
      > Works for Java 1.4+ .
      > You can also print the stories with
      > ant print-example-stories
      > They end up in delete_me\1.1-SNAPSHOT (I really should overwrite the ones
      > in the stories directory, shouldn't I?)
      >> There is no indication of user input, and
      >> there is no indication of how and in what state most of the objects
      > appear,
      >> and there is no indication of what keys are used for left, right,
      >> rotate, and
      >> drop, and there is no indication how the current state is known, and on
      > and
      >> on and on. There is no program logic here, only known and fixed states.
      > Well, I only posted a small snippet of the code. However, "the player
      > presses the right-rotate key" is user input; you could actually perform
      > these scenarios yourself as a user. I could have used 'the player presses
      > the x key', it's true. In a future version I might give the user the
      > ability to change the keys, so I kept the wording robust.
      > For interest, here's the code for 'The player presses right rotate', and
      > the relevant snip from HellboundEvent :
      > --
      > public class ThePlayerPressesRightRotate extends HellboundEvent {
      > protected void occurAnyTimeIn(World world) {
      > pressKey('x', world);
      > }
      > }
      > --
      > public abstract class HellboundEvent extends EventUsingMiniMock {
      > // ...
      > protected abstract void occurAnyTimeIn(World world);
      > // ...
      > protected void pressKey(char keychar, World world) {
      > WindowWrapper wrapper = (WindowWrapper)
      > world.get(WorldKey.WINDOW_WRAPPER, null);
      > try {
      > wrapper.pressKeychar(keychar);
      > } catch (TimeoutException e) {
      > throw new RuntimeException(e);
      > }
      > }
      > }
      > --
      > WindowWrapper, EventUsingMiniMock and the World are part of JBehave's
      > framework. (We've made the world nicer since I wrote this).
      > With respect to the 'known states' - those states come from other
      > scenarios, the logic to which I hadn't posted. Those scenarios go back to
      > the only true given, 'Hellbound is running', then progress solely through
      > user-input. The other scenarios are similarly english-readable (one of the
      > scenarios I posted is such a GivenScenario).
      > For info, keys are:
      > drop = space
      > z = left-rotate
      > x = right-rotate
      > directions = arrows.
      >> And, the program is not even playing the game
      > It really is playing the game; I hooked the Swing harness which performs
      > those scenarios into the buttons and key strokes.
      >> the knowledge of all those things mentioned above is being supplied by
      > the programmer.
      > I had my 'customer' hat on when I wrote the stories, which were written
      > before the code. Since the Java version is just an extrapolation of the
      > English, they were pretty easy. They changed a bit with the round-trip
      > through the StoryRenderer, but not too much (and IMHO they are still
      > readable).
      >> Maybe all that you intended to show was the naming convention for
      > objects,
      >> and methods, but I would have to see some actual program logic before
      >> this would make much sense to me.
      > This is actual, real, programming logic. Try it out (instructions for how
      > above).
      > The main class for running the game itself is
      > com.sirenian.hellbound.Hellbound; you can just run it, with no arguments.
      > Cheers,
      > Liz.
      > --
      > Elizabeth Keogh
      > liz@...
      > http://sirenian.livejournal.com
      > http://jbehave.org
      > [Non-text portions of this message have been removed]
      > To Post a message, send it to: extremeprogramming@...
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links

      [Non-text portions of this message have been removed]
    • William Tozier
      ... Can t resist: Now is the funny word in that sentence. ... Bill Tozier AIM: vaguery@mac.com; Skype: vaguery; Twitter: Vaguery
      Message 154 of 154 , May 2, 2007
        On May 2, 2007, at 5:58 AM, Elizabeth Keogh wrote:

        > I think you're being picky now.

        Can't resist: "Now" is the funny word in that sentence.
        Bill Tozier
        AIM: vaguery@...; Skype: vaguery; Twitter: Vaguery

        "People who write obscurely are either unskilled in writing or up to
        -- Sir Peter Medawar
      Your message has been successfully submitted and would be delivered to recipients shortly.