PHPUnit：测试没有具体方法的抽象类

我已经学习了以下抽象类，并且有一个关于如何为此编写单元测试的问题。这真的需要吗？因为这个类没有任何具体的方法

<?php

abstract class PickupPoint_Abstract {
    public function __construct($client) {}
    public function getPickupPoints($countryCode, $postalCode, $city) {}
    public function getPickupPointDetails($pickupPointId, $countryCode) {} }

---

不，您不需要测试它，因为没有什么需要测试的

顺便说一下，抽象方法的定义如下

<?php
abstract class PickupPoint_Abstract {
    public function __construct($client) {}
    abstract public function getPickupPoints($countryCode, $postalCode, $city);
    abstract public function getPickupPointDetails($pickupPointId, $countryCode);
}
?>

您创建了钩子，这可能不会被覆盖

---

请参阅。

由于您无法测试任何预期行为，因此很难生成任何有意义的测试

---

如果您至少有一个具体的方法，您可以模拟类并测试该方法，但不需要测试任何代码，我认为您可以继续

（我想你总是知道，但为了完成：）

---

即使如此，我还是很好奇为什么你没有像这样将方法定义为抽象的：

<?php
abstract class PickupPoint_Abstract {
    abstract public function __construct($client);
    abstract public function getPickupPoints($countryCode, $postalCode, $city);
    abstract public function getPickupPointDetails($pickupPointId, $countryCode); }

---

对于这种情况和测试接口，我将编写至少3个测试：

protected setUp() {
    $this->_object = $this->getMockForAbstractClass(
       'PickupPoint_Abstract', array(), '', false
    );
}

public function testInstanceOf() {
    $this->assertInstanceOf('PickupPoint_Abstract', $this->_object);
}

public function testMethodsExistance() {
    $methods = get_class_methods($this->_object);
    $this->assertTrue(in_array('getPickupPoints', $methods));
    $this->assertTrue(in_array('getPickupPointDetails', $methods));
    $this->assertTrue(in_array('__construct', $methods));
}

public function testMethodCount() {
    $methods = get_class_methods($this->_object);
    /**
     * PHPUnit add seven own methods in 3.6.11 + __clone + count of these methods
     */
    $this->assertEquals(11, count($methods));
}

通过这些测试，您将防止输入错误，检查所需方法的存在性，如果将添加任何新方法，此测试将被中断，因为方法的数量已更改，这是我们想要的行为

这对我来说很好。我总是对接口使用这种测试，但我认为它可以用于抽象类
 这不是一个抽象类，而是一个接口。抽象类定义了方法存根和实现的方法。可能是我忘记了抽象的重复！Thx.我礼貌地不同意，我认为op声明方法的方式可以在子类中重写，它们只是不需要定义，因此它们不是抽象的。在这样的上下文中，抽象就像一个定义了所有函数的常规类，忽略了真正的OOP抽象。我不理解你的评论。你不同意什么？