How should I test this method? - php

Question

I've been trying to adopt TDD methodologies in my projects lately but I have a hard time knowing how to test certain pieces of code. I've read quite a bit on the subject but I have a hard time taking that and putting it into practice. Since that is the case, I'm going to post my method and ask how you would try to test it.
public function simulate(){
while (!isComplete()) {
if ($this->currentOuts == 3) {
advanceInning();
} else {
$batter = getBatter();
$pitcher = getPitcher();
$atBat = new AtBat($batter, $pitcher);
$result = $atBat->simulate();
handleAtBatResult();
}
}
}
Assume that all function calls inside of simulate are being tested properly. Is there really anything else to test? Maybe that certain functions are called? Does the lack of obvious testing (at least to me) point to design issues?

Answer 1

When starting out using TDD I ended up asking the same questions you are asking here. After some research, and several weeks of working with unit tests etc, I came up with two terms; "flow testing", and "module testing".
Module Testing: As engineers we should be working hard to follow the DRY (don't repeat yourself) principle, as such, we end up with abstract pieces of code, which get pushed to the lowest layer of application, so they can be used anywhere. These pieces of code, whether methods of a class or stand alone functions should be atomically testable, meaning that there is the lowest possible dependence on any other modules, functions, etc. Obviously this becomes avoidable as you work on methods/functions which incorporate several modules, but this is where flow testing comes into play.
Flow Testing: With all of our basic modules in a testable state, we need to also be able to test them in scenarios commensurate with real world requirements. In order to flow test correctly, we need to establish what I refer to as "known goods". What this means is we construct data which mirrors the return value of modules within in the flow test, so we can compare them against the values generated from the API.
To help demonstrate these ideas better, here is a flow test I did for testing my cache api (added some extra comments to explain better):
<?php
class HobisTest_Api_Flow_CacheTest extends PHPUnit_Framework_TestCase
{
// Setting some constants so it's easier to construct known goods
const TEST_EXPIRY = 30;
const TEST_KEY_PREFIX = 'test';
const TEST_VALUE = 'brown chicken, brown cow';
//-----
// Support methods
//-----
protected $object;
protected $randomNumber;
// Here we generate a known good key, this allows us to test that the api internal workings generate what we expect
protected function getKnownGoodKey()
{
return self::TEST_KEY_PREFIX . Hobis_Api_Cache_Key::SEPARATOR . $this->getRandomNumber() . Hobis_Api_Cache_Key::SEPARATOR . '1';
}
protected function getObject()
{
return $this->object;
}
protected function getRandomNumber()
{
return $this->randomNumber;
}
//-----
//-----
// Setup and teardown
//-----
// You will want to add setup and teardown functions to your test classes
// These allow you to reference items for EVERY test within the current class
// While ensuring they are not carried over from one test to the other
// Basically a clean slate for every test
public function setUp()
{
$this->object = $this->getMock('Hobis_PhpUnit_DefaultTestObject');
$this->randomNumber = mt_rand();
}
public function tearDown()
{
unset(
$this->object,
$this->randomNumber
);
}
//-----
//-----
// Test methods
//-----
// The actual test method
public function testCache()
{
// Configure object
// Setting up so any references to $this->getId() will return 1
// If you look in the getKnownGoodKey() it is constructed with 1 as well
$this->object->expects($this->any())->method('getId')->will($this->returnValue(1));
// So now I am calling on my API to generate a cache key based on
// values used here, and when I constructed my "known good" key
$key = Hobis_Api_Cache_Key_Package::factory(
array(
'dynamicSuffixes' => array($this->getRandomNumber(), $this->getObject()->getId()),
'expiry' => self::TEST_EXPIRY,
'staticPrefix' => self::TEST_KEY_PREFIX,
'value' => self::TEST_VALUE
)
);
// Calling set via api
$setStatus = Hobis_Api_Cache_Package::set($key);
// Check that call was what we expect
$this->assertTrue($setStatus);
// Now let's retrieve the cached value so we can test if it's available
$cachedValue = Hobis_Api_Cache_Package::get($key);
// Test the attributes against "known good" values
$this->assertSame($key->getKey(), $this->getKnownGoodKey());
$this->assertSame($cachedValue, self::TEST_VALUE);
}
//-----
}

Answer 2

If a function is hard to test, it is a code smell. What is making it difficult to test and can it feasibly be changed to make that easier.
In your case, it seems to me that you function is doing too many things. You are checking if the simulation is complete, getting the batter and the pitcher, and simulating the at-bat. When you are describing if what the function does and you use the word 'AND', break up the functionality.
You are also suffering from a lack of dependency injection, so you can't pass in the mock objects ($batter and pitcher).
You also want to avoid using new in your functions (except if it is part of a factory) You can't replace that object and are dependent on the functionality that the class has. You are now unable to control what that object does.
Update
RE: your comment about the advanceInning and isComplete being moved to someObject. Think about things in terms of behavior. Don't just put a function into an object just because. I would have a Game object that would have isComplete and playNextInning as the public methods. What objects you are going to have all depend on your abstractions and what you are trying to achieve. Your objects should represent and be responsible for one thing. You have a game which represents the game. Each game has an inning, so you will probably have an inning object. You have two teams, so you will likely have a team object. You may want to have an inning factory that will create innings for you, that you pass into the game constructor (then you can mock it when you do testing). Depending on the logic that you end up with, you may even abstract the half innings into objects. That will all be determined by the behavior that you are trying to achieve.
You will find that you end up with ton of really small objects which is a GOOD THING. As your design will be flexible and more extensible.