[General boards] [Winter 2019 courses] [Fall 2018 courses] [Summer 2018 courses] [Older or newer terms]

Potentially extra tests


#1

In general, if based on our own implementation, the results of two tests will always be the same, should we still include both in case that the implementation is very different in the version for testing?

For example, a Fish should not collide with any other entity, also a Fish should not eat the whole seaweed. The tests for these two seem to be repetitive since a seaweed is an entity and both are just checking if the Fish would turn around; however, if another implementation treats seaweed differently then the tests may not give the same results. Do we include both?

Also, I made HungryFish a subclass of Fish; and since we cannot change constructor, the HungryFish is still there but has nothing but a constructor. In this case, do we still need to write separate (and essentially the same) tests for HungryFish since in other implementation the inheritance may not exist?

Thanks!!


#2
  1. HungryFish defines no explicit behavior, so you don’t need any tests specifically for it if you choose to make it a subclass of fish

  2. You need to keep the class, but it’s fine to make it just a constructor

  3. It’s probably fine to make a general “should not collide” test for each entity – the specifics are for the thing that is moving, not really for the thing it is colliding with.


#3

If we don’t need any extra tests for HungryFish, should we create a HungryFishTest class that extends FishTest but has nothing?


#4

No, you don’t need an empty test class for hungry fish


#5

If there is no test class for hungry fish and in another implemention the hungry fish does not extend fish, then would this imply that the behaviour of hungry fish cannot be tested? I was thinking about having a child test class that only overrides the set up method to initialize the object as a hungry fish to avoid such scenario.


#6

I mean, the specifications don’t actually mention hungry fish at all, so there really isn’t anything to be tested except for that it exists and does the same sorts of things Fish does


#7

Then how should we test that hungry fish does the same things as fish without any test class? (or is it guaranteed that the implemention that you are using makes hungry fish an empty subclass?)


#8

Yeah, if it’s just an empty subclass, there really isn’t anything to test – in general a good testing philosophy is to avoid copy/pasting tests without changes if they refer to a superclass