如果测试访问器是浪费时间，那么测试构造函数逻辑呢？

It seems that many people think that unit testing setters and getters is just a waste of time, and the accessors should be tested only when contain some sort of logic. I agree.

But what about properties that require some (small amout of) logic?

class DeliveryReportEvent extends Event
{
    private static $reasonMap = array(
        '401' => "Message expired (device off/not reachable)",
        '201' => "Operator network malfunctioning",
        '203' => "Recipient unreachable (in roaming)",
        '301' => "Invalid recipient (nonexistent/on portability/not enabled)",
        '302' => "Wrong number",
        '303' => "SMS service not enabled",
    );

    private $errorCode;

    public function __construct($errorCode)
    {
        $this->errorCode = $errorCode;

        if(array_key_exists($errorCode, self::$reasonMap)) {
            $this->errorReason = self::$reasonMap;
        }
    }

    public function getErrorCode()
    {
        return $this->errorCode;
    }

    public function getErrorReason()
    {
        return $this->errorReason;
    }
}

While testing getErrorCode() may sound stupid (because the absence of logic and IDE features), do you thing that testing getErrorReason() makes sense?

/**
 * @dataProvider getKnownErrorCodesAndReasons
 */
public function testErrorReasonWithKnownErrorCodes($knownErrorCode,
    $expectedErrorReason)
{
    $event = $this->getMockDeliveryReportEvent($knownErrorCode);

    $actualErrorReason = $event->getErrorReason();

    $this->assertNotNull($errorReason);
    $this->assertContains($expectedErrorReason, $actualErrorReason, '', true);
}

public function getKnownErrorCodesAndReasons()
{
    return array(
        array('401', "expired"),
        array('201', "network malfunctioning"),
        array('203', "unreachable"),
        array('301', "invalid recipient"),
        array('302', "wrong number"),
        array('303', "not enabled"),
    );
}

It is all subjective and depends on many factors such as:

• what level of code coverage do you want your test cases to have? Some release management systems define this coverage and need it to be satisfied along with other criteria before release confirmation.
• Is the getErrorReason() a critical function (in-spite of how small its internal logic is)? In other words will it break the system if it gets messed up?

Also depends on other factors like:

• How much free time do you have?
• How much of a purist are you?
• Do you have a mustache?

etc, etc.. :)