Up to Main Index                             Up to Journal for April, 2013

                    JOURNAL FOR THURSDAY 25TH APRIL, 2013
______________________________________________________________________________

SUBJECT: Item testing and code digging
   DATE: Thu Apr 25 21:58:04 BST 2013

So yesterday was another WolfMUD Wednesday... What was I doing?

I started working on the tests for the item package.

The first problem I noticed was that this was the first time I'd tried using
non-string values with the recordjar package. Not a problem in itself as I'd
already written the package decode routines.

I was creating test subjects from structs that matched the New methods - now
they match the exported structs. For example the item test subjects were
created using:


  var testSubjects = []struct {
    name        string
    alias       []string
    description string
    weight      units.Weight
  }{
    {"Item1", []string{"item1"}, "Test Item 1", 1},
    {"Item2", []string{"item2"}, "Test Item 2", -1},
    {"Item3", []string{"item3"}, "Test Item 3", 0},
  }


This presents something of a catch-22. The weight can either be a numeric - as
in the above snippet. This then needs converting to a string for use with a
RecordJar as in:


  func new(name string, aliases []string, description string,
                                                  weight units.Weight) *Item {
    item := &Item{}
    item.Unmarshal(recordjar.Record{
      "name":    name,
      "aliases": strings.TrimSpace(strings.Join(aliases, " ")),
      ":data:":  description,
      "weight":  strconv.Itoa(weight.Int()),
    })
    return item
  }


This has the advantage that struct members can be compared directly during
testing. For example when testing the Unmarshal:


  for _, s := range testSubjects {
    item := new(s.name, s.alias, s.description, s.weight)
    have := item.weight
    want := s.weight
    if have != want {
      t.Errorf("Invalid weight: have %d wanted %d", have, want)
    }
  }


The alternative is to have weight as a string in testSubjects, pass it
directly to the RecordJar and convert it for every test. I decided to go with
the 'convert once' for the RecordJar as I like to try and keep the tests as
lean as possible.

Anyway while writing the tests some failed that I was expecting to pass. So I
started digging into the item code. The test results were correct and should
indeed have failed. However the digging got me to look again at the item get
and drop methods and the restrictions on the conditions that have to be valid
for a get or drop to be successfully handled.

While chasing down the get and drop issues I started digging into the chain of
Process calls made when parsing and acting on a command. In doing do I noticed
that for some reason, probably early code, inventories had a Delegate method
which had the same signature as the command.Processor interface but no Process
method! *sigh*

I actually have a note about items, get & drop and inventories. It says
"Change get and drop on item to use inventories and not locations - make
inventories pivotal". Hrm...

Upshot of all this is I'm fixing inventories to be a regular command
processors, looking at making item get and drop methods more versatile and
still writing the item tests.

--
Diddymus


  Up to Main Index                             Up to Journal for April, 2013