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