tdd:spock工作原理_以TDD方式升级Sylius：探索PhpSpec

曾经终败给现在 2022-12-03 09:11 85阅读 0赞

tdd:spock工作原理

*This article was peer reviewed by [Christopher Pitt][]. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!*

*本文由[Christopher Pitt][]同行评审。* *感谢所有SitePoint的同行评审人员使SitePoint内容达到最佳状态！*

The [post on developing and testing new Sylius features][] was an introduction to the three types of tests that are used in Sylius – [PHPUnit][], [Phpspec][] and [Behat][].

在[开发和测试新Sylius功能后][post on developing and testing new Sylius features]是介绍了三种类型的测试，在使用Sylius - [PHPUnit的][PHPUnit] ， [Phpspec][]和[贝哈特][Behat] 。

In this part, we’ll extend some core classes to indicate color-coded inventory status. First, we’ll deal with the back end part. In a followup post, we’ll use Behat and test the visual changes. Please follow the instructions in the [previous post][post on developing and testing new Sylius features] to get a working instance up and running.

在这一部分中，我们将扩展一些核心类来指示颜色编码的库存状态。 首先，我们将处理后端部分。 在后续文章中，我们将使用Behat并测试外观变化。 请按照[上][post on developing and testing new Sylius features]一篇[文章中][post on developing and testing new Sylius features]的说明启动并运行工作实例。

--------------------

![Sylius logo][]

Sylius has an excellent [inventory management solution][]. However, there’s always some room for a tweak or two. If you look at the list of products (admin/products) there’s no information about available stock. Looking at the variants of a product, we see inventory data, whether it’s tracked or not, and the number of total items in stock, if tracked. It would be nice to see that kind of information on the product listing page, too. In addition, the stock level is all or nothing – for example, a green label says “10 Available on hand” or red “0 Available on hand”. How about something in-between, say a yellow label for “3 Available on hand” to indicate that stock is low? Then, the store admin can decide it’s time to replenish.

Sylius具有出色的[库存管理解决方案][inventory management solution] 。 但是，总会有一些空间可以进行一两个调整。 如果您查看产品列表(管理员/产品)，则没有可用库存的信息。 查看产品的变型，我们可以查看库存数据(是否跟踪)以及库存(如果跟踪)的总项目数。 也很高兴在产品列表页面上看到此类信息。 此外，库存水平为全有或全无-例如，绿色标签显示“ 10手头可用”或红色“ 0手头可用”。 中间有什么东西，比如说“ 3手头可用”的黄色标签表示库存不足？ 然后，商店管理员可以决定是时候补货了。

## 扩展ProductVariant和产品模型 **(**Extend ProductVariant and Product models**)** ##

We want to extend the behavior of both the `ProductVariant` and `Product` models provided by Sylius, so we can see extra information on stock availability when viewing products.

我们想扩展Sylius提供的`ProductVariant`和`Product`模型的行为，以便在查看产品时可以看到有关库存状况的更多信息。

### 创建捆绑 **(**Create a Bundle**)** ###

First, we create the `src/AppBundle/AppBundle.php` file and register it in `app/AppKernel.php`.

首先，我们创建`src/AppBundle/AppBundle.php`文件并将其注册到`app/AppKernel.php` 。

<?php
    
    // src/AppBundle/AppBundle.php
    
    namespace AppBundle;
    
    use Symfony\Component\HttpKernel\Bundle\Bundle;
    
    class AppBundle extends Bundle
    {
    }

<?php
    
    // app/AppKernel.php
    
    public function registerBundles()
    {
        $bundles = [
            // ...
            new AppBundle\AppBundle(),
        ];
    }

Next, we inform the autoloader about the new bundle by adding it to the “autoload” section of `composer.json`.

接下来，我们通过将新捆绑包添加到`composer.json`的“ autoload”部分来通知自动装载器。

{
      // ...
      "autoload": {
        "psr-4": {
          // ...
          "AppBundle\\": "src/AppBundle"
        }
      }
      // ...
    }

We then run `composer dump-autoload` to re-generate autoloader information. Now, we can start writing some SpecBDD tests.

然后，我们运行`composer dump-autoload`以重新生成自动加载器信息。 现在，我们可以开始编写一些SpecBDD测试。

### 编写SpecBDD测试 **(**Writing SpecBDD tests**)** ###

Our tests will focus on how our `Product` and `ProductVariant` classes help us achieve the goals we set for the implementation of the features we described above. Phpspec needs to know about our tests. We open `phpspec.yml.dist` and add the following under “suites”:

我们的测试将重点关注`Product`和`ProductVariant`类如何帮助我们实现为实现上述功能而设定的目标。 phpspec需要了解我们的测试。 我们打开`phpspec.yml.dist`并在“ suites”下添加以下内容：

AppBundle: { namespace: AppBundle\Entity, psr4_prefix: AppBundle\Entity, spec_path: src/AppBundle/Entity, src_path: src/AppBundle/Entity }

It might be good to clear the cache now: `php bin/console cache:clear`. The next thing to do is to have specs where we write the expected behavior of our classes and Phpspec is able to assist us with that right from the start. The `describe` command is the starting point and it creates a specification class:

最好现在清除缓存： `php bin/console cache:clear` 。 接下来要做的是制定规范，在其中编写我们的类的预期行为，Phpspec可以从一开始就帮助我们。 `describe`命令是起点，它创建一个规范类：

php bin/phpspec desc AppBundle/Entity/ProductVariant

The result:

结果：

Specification for AppBundle\Entity\ProductVariant created in src/AppBundle/Entity/spec/ProductVariantSpec.php

Let’s run it.

让我们运行它。

php bin/phpspec run src/AppBundle/Entity/spec/ProductVariantSpec.php

The class, `ProductVariant`, described in the spec doesn’t exist but Phpspec will offer to create it for us. After it’s been created, we can repeat the two steps above to get our `Product` class, too.

规范中描述的`ProductVariant`类不存在，但Phpspec会为我们创建它。 创建它之后，我们也可以重复上述两个步骤来获得我们的`Product`类。

php bin/phpspec desc AppBundle/Entity/Product
    php bin/phpspec run src/AppBundle/Entity/spec/ProductSpec.php

Sylius already has these two classes so we need to extend them in our AppBundle. Since Sylius uses interfaces a lot, we create those too.

Sylius已经拥有了这两个类，因此我们需要在AppBundle中对其进行扩展。 由于Sylius经常使用接口，因此我们也创建了这些接口。

<?php
    
    // src/AppBundle/Entity/ProductInterface.php
    
    namespace AppBundle\Entity;
    
    use Sylius\Component\Core\Model\ProductInterface as BaseProductInterface;
    
    interface ProductInterface extends BaseProductInterface
    {
    }

<?php
    
    // src/AppBundle/Entity/ProductVariantInterface.php
    
    namespace AppBundle\Entity;
    
    use Sylius\Component\Core\Model\ProductVariantInterface as BaseProductVariantInterface;
    
    interface ProductVariantInterface extends BaseProductVariantInterface
    {
    }

<?php
    
    // src/AppBundle/Entity/Product.php
    
    namespace AppBundle\Entity;
    
    use Sylius\Component\Core\Model\Product as BaseProduct;
    use AppBundle\Entity\ProductInterface;
    
    class Product extends BaseProduct implements ProductInterface
    {
    }

Let’s update the generated `ProductVariant` class with the `$reorderLevel` property we want to introduce.

让我们使用我们要介绍的`$reorderLevel`属性更新生成的`ProductVariant`类。

<?php
    
    // src/AppBundle/Entity/ProductVariant.php
    
    namespace AppBundle\Entity;
    
    use AppBundle\Entity\ProductVariantInterface as ProductVariantInterface;
    use Sylius\Component\Core\Model\ProductVariant as BaseProductVariant;
    
    class ProductVariant extends BaseProductVariant implements ProductVariantInterface
    {
        const REORDER_LEVEL = 5;
    
        /**
         * @var int
         */
        private $reorderLevel;
    
    }

### 覆盖Sylius类 **(**Overriding Sylius classes**)** ###

Let’s inform Sylius about our classes so that they will be used in place of the ones provided by Sylius. We append the following to `app/config/config.yml`:

让我们向Sylius告知我们的类，以便将其替换为Sylius提供的类。 我们将以下内容附加到`app/config/config.yml` ：

sylius_product:
        resources:
            product:
                classes:
                    model: AppBundle\Entity\Product
            product_variant:
                classes:
                    model: AppBundle\Entity\ProductVariant

We’ve added a `$reorderLevel` property that defaults to 5 to the `ProductVariant` class. Since this will differ from variant to variant, we need to alter the `product_variant` table so that we can store this information, too. Since Sylius uses Doctrine ORM, that’s the way to go. To extend the existing table definition, let’s create `src/AppBundle/Resources/config/doctrine/ProductVariant.orm.yml`, and add this:

我们向`ProductVariant`类添加了一个默认为5的`$reorderLevel`属性。 由于不同的变量会有所不同，因此我们需要更改`product_variant`表，以便我们也可以存储此信息。 由于Sylius使用Doctrine ORM，因此就是这种方式。 为了扩展现有的表定义，让我们创建`src/AppBundle/Resources/config/doctrine/ProductVariant.orm.yml`并添加以下内容：

AppBundle\Entity\ProductVariant:
        type: entity
        table: sylius_product_variant
        fields:
            reorderLevel:
                column: reorder_level
                type: integer
                nullable: true

The key for the field is the property name on the model. We have to specify the column name, otherwise Doctrine defaults to the property name of “reorderLevel”. If the property is a single word e.g. “level”, then the column can be left out of this configuration.

该字段的关键字是模型上的属性名称。 我们必须指定列名称，否则Doctrine默认为属性名称“ reorderLevel”。 如果属性是单个单词(例如“ level”)，则可以将该列保留在此配置之外。

Next, let’s create `src/AppBundle/Resources/config/doctrine/Product.orm.yml` and add this:

接下来，让我们创建`src/AppBundle/Resources/config/doctrine/Product.orm.yml`并添加以下内容：

AppBundle\Entity\Product:
        type: entity
        table: sylius_product

It’s empty, but we’re saying our extended Product model still stores data in the unmodified table.

它为空，但是我们说扩展的产品模型仍将数据存储在未修改的表中。

### 更新数据库 **(**Updating the database**)** ###

Let’s run the following:

让我们运行以下命令：

php bin/console doctrine:migrations:diff

This command generates a migration class in `app/migrations`. It’s usually the last one since the name includes a timestamp. It contains SQL statements to alter the `product_variant` table. In real projects, the generated code may not suffice but you may edit the file to meet your requirements. To migrate:

此命令在`app/migrations`生成一个迁移类。 由于名称包含时间戳记，因此通常是最后一个。 它包含用于更改`product_variant`表SQL语句。 在实际的项目中，生成的代码可能不够用，但是您可以编辑文件以满足您的要求。 要迁移：

php bin/console doctrine:migrations:migrate

If this fails for some reason, try the following instead:

如果由于某种原因失败，请尝试以下方法：

php bin/console doctrine:schema:update --force

### 编写更多SpecBDD测试 **(**Writing more SpecBDD tests**)** ###

Now that we’ve got our models and database configured, let’s go back to our tests. Our first two examples should now give green results because the classes have been created. Let’s confirm with:

现在我们已经配置了模型和数据库，让我们回到测试中。 现在，我们的前两个示例应该会给出绿色结果，因为已经创建了类。 让我们确认一下：

php bin/phpspec run -fpretty --verbose src/AppBundle/Entity/spec/ProductVariantSpec.php

<?php
    
    // src/AppBundle/Entity/spec/ProductVariantSpec.php
    
    namespace spec\AppBundle\Entity;
    
    use AppBundle\Entity\ProductVariant;
    use PhpSpec\ObjectBehavior;
    use Prophecy\Argument;
    
    class ProductVariantSpec extends ObjectBehavior
    {
        function it_is_initializable()
        {
            $this->shouldHaveType(ProductVariant::class);
        }
    }

`$this` represents a special object that will behave exactly like our `ProductVariant` class. However, it will only have properties and methods we specify in the examples. Let’s add a method to the spec class.

`$this`表示一个特殊对象，其行为与我们的`ProductVariant`类完全相同。 但是，它将仅具有我们在示例中指定的属性和方法。 让我们向spec类添加一个方法。

function it_has_reorder_level_by_default()
    {
       $this->getReorderLevel()->shouldReturn(ProductVariant::REORDER_LEVEL);
    }

We’d like our `ProductVariant` to have a reorder level value of 5 by default. Remember that our `ProductVariant` class is still empty. Let’s try and run the spec. The test fails nicely, with a hint:

我们希望我们的`ProductVariant`默认情况下的重新订购级别值为5。 请记住，我们的`ProductVariant`类仍然为空。 让我们尝试运行该规范。 测试很好地失败了，并提示：

Do you want me to create
      `AppBundle\Entity\ProductVariant::getReorderLevel()` for you?

![Running Phpspec and getting confirmation for auto-creating a method][]

If we confirm, the `getReorderLevel()` method is stubbed out in the class. Phpspec expected to find `getReorderLevel()` which returns an integer, representing the inventory threshold below which the stock should be replenished. All we have to do in the method is return the `$reorderLevel` property.

如果我们确认，则`getReorderLevel()`方法将在类中存根。 phpspec期望找到`getReorderLevel()` ，该`getReorderLevel()`返回一个整数，该整数表示库存阈值，低于该阈值应补充库存。 我们在方法中要做的就是返回`$reorderLevel`属性。

Normally, `return $this->reorderLevel;` would be sufficient but we’ve already got products in our store so we need to find a way to get our default reorder level value. One way of doing this is:

通常， `return $this->reorderLevel;` 足够了，但是我们已经在商店中购买了产品，因此我们需要找到一种方法来获取默认的重新订购级别值。 一种方法是：

/**
     * @return int
     */
    public function getReorderLevel()
    {
        return !empty($this->reorderLevel) ? $this->reorderLevel : self::REORDER_LEVEL;
    }

The test passes. We may update the `ProductVariantInterface` with `public function getReorderLevel();`. Next, we want to make sure that we can set the reorder level. Here’s the example:

测试通过。 我们可以使用`public function getReorderLevel();`更新`ProductVariantInterface` `public function getReorderLevel();` 。 接下来，我们要确保可以设置重新订购级别。 例子如下：

function it_has_reorder_level()
    {
        $this->setReorderLevel(10);
        $this->getReorderLevel()->shouldReturn(10);
    }

When we run it, Phpspec will know there’s no `setReorderLevel()` method and offer to create it. Update the created method as follows:

当我们运行它时，Phpspec将知道没有`setReorderLevel()`方法并愿意创建它。 更新创建的方法，如下所示：

/**
     * @param int $reorderLevel
     */
    public function setReorderLevel($reorderLevel)
    {
        $this->reorderLevel = $reorderLevel;
    }

We run it, and it’s all green. Don’t forget to update the interface, too. Now, we want to check if an item can be reordered, i.e. if it should be flagged as low enough to have it replenished. It has to be tracked and the quantity on hand has to be lower than or equal to the reorder level:

我们运行它，它全是绿色的。 也不要忘记更新界面。 现在，我们要检查某个项目是否可以重新排序，即是否应将其标记为足够低以使其得到补充。 必须对其进行跟踪，并且现有数量必须小于或等于再订购水平：

function it_is_reorderable_when_tracked_and_available_stock_is_at_reorder_level()
    {
        $this->setTracked(true);
        $this->setOnHand(3);
        $this->setReorderLevel(4);
        $this->isReorderable()->shouldReturn(true);
    }

When we run the spec, it finds all methods except `isReorderable()` which it offers to create for us in the `ProductVariant` class.

运行规范时，它将找到除`isReorderable()`之外的所有方法，该方法可以在`ProductVariant`类中为我们创建。

![Another offer to create a method][]

In the method, we need to check that the variant is trackable and the quantity on hand is less than or equal to the reorder level.

在该方法中，我们需要检查变体是否可跟踪以及现有数量是否小于或等于再订购水平。

public function isReorderable()
    {
      return $this->isTracked() && ($this->getOnHand() <= $this->getReorderLevel());
    }

All tests pass. Let’s update the interface with `public function isReorderable();`. You might also want to add a test for when the available stock is more than the reorder level: it shouldn’t be re-orderable.

所有测试均通过。 让我们使用`public function isReorderable();`更新接口`public function isReorderable();` 。 您可能还想添加一个测试，以检查可用库存何时超过了重新订购水平：不应重新订购。

function it_is_not_reorderable_when_tracked_and_available_stock_is_greater_than_reorder_level()
    {
        $this->setTracked(true);
        $this->setOnHand(10);
        $this->setReorderLevel(4);
        $this->isReorderable()->shouldReturn(false);
    }

Running the spec now should give us something like this:

现在运行规范应该给我们这样的东西：

![Five passing tests][]

We’re done with `ProductVariant`. We will do something similar with the variants that are in a product, but in a slightly different way. We need a product for each example we write and it would be tedious to create a product with at least two variants for each.

我们已经完成了`ProductVariant` 。 我们将对产品中的变体进行类似的操作，但方式略有不同。 对于我们编写的每个示例，我们都需要一个产品，而为每个示例创建至少具有两个变体的产品将很繁琐。

In Phpspec, we can write a `let()` method that gets called before each example and `letGo()` after it’s been run. In `src/AppBundle/Entity/spec/ProductSpec.php`, we’ll add the following while remembering to import `ProductVariantInterface` with `use AppBundle\Entity\ProductVariantInterface as VariantInterface;` at the top of the class.

在Phpspec中，我们可以编写一个`let()`方法，该方法在每个示例之前被调用，而`letGo()`在其运行之后被调用。 在`src/AppBundle/Entity/spec/ProductSpec.php` ，我们将添加以下内容，同时记住`use AppBundle\Entity\ProductVariantInterface as VariantInterface;`导入`ProductVariantInterface` `use AppBundle\Entity\ProductVariantInterface as VariantInterface;` 在全班最高。

function let(VariantInterface $firstVariant, VariantInterface $secondVariant)
    {
        $firstVariant->setOnHand(4);
        $firstVariant->getOnHand()->willReturn(4);
        $firstVariant->setReorderLevel(4);
        $firstVariant->getReorderLevel()->willReturn(4);
        $firstVariant->isTracked()->willReturn(true);
        $firstVariant->isReorderable()->willReturn(true);
        $firstVariant->setProduct($this)->shouldBeCalled();
        $this->addVariant($firstVariant);
    
        $secondVariant->setOnHand(10);
        $secondVariant->getOnHand()->willReturn(10);
        $secondVariant->setReorderLevel(3);
        $secondVariant->getReorderLevel()->willReturn(3);
        $secondVariant->isTracked()->willReturn(true);
        $secondVariant->isReorderable()->willReturn(false);
        $secondVariant->setProduct($this)->shouldBeCalled();
        $this->addVariant($secondVariant);
    }

We can now proceed with writing examples and making sure our tests are green each step of the way:

现在，我们可以继续编写示例，并确保测试的每一步都是绿色的：

php bin/phpspec run -fpretty --verbose src/AppBundle/Entity/spec/ProductSpec.php

The first thing we want to ensure is that the on-hand quantity of a product is a sum of on hand variants in the product. In `ProductSpec.php`, we add this example:

我们要确保的第一件事是产品的现有数量是产品中现有变型的总和。 在`ProductSpec.php` ，我们添加以下示例：

function it_gets_products_on_hand_as_sum_of_product_variants_on_hand()
    {
        $this->getVariants()->shouldHaveCount(2);
        $this->getOnHand()->shouldReturn(14);
    }

Of course, when you run it, the `Product` class doesn’t have a `getOnHand()` method so we ask Phpspec to create it for us before we implement it.

当然，当您运行它时， `Product`类没有`getOnHand()`方法，因此我们要求Phpspec在实现它之前为我们创建它。

public function getOnHand()
    {
        $onHand = 0;
        foreach ($this->getVariants() as $variant) {
            if ($variant->isTracked()) {
                $onHand += $variant->getOnHand();
            }
        }
    
        return $this->onHand = $onHand;
    }

We mustn’t forget to add `public function getOnHand();` to the `ProductInterface`, too.

我们一定不要忘记添加`public function getOnHand();` 到`ProductInterface` 。

Finally, a product is re-orderable when at least one of its variants is re-orderable. The example is as follows:

最后，当产品的至少一个变体可重新订购时，该产品是可重新订购的。 示例如下：

function it_recognizes_when_to_reorder_stock() {
        $this->isReorderable()->shouldReturn(true);
    }

Again, we let Phpsepc create the `isReorderable()` method. Let’s update the `ProductInterface` with `public function isReorderable();`. The complete implementations should be:

同样，我们让Phpsepc创建`isReorderable()`方法。 让我们使用`public function isReorderable();`更新`ProductInterface` `public function isReorderable();` 。 完整的实现应为：

public function isReorderable() {
        $variants = $this->getVariants();
        $trackedVariants = $variants->filter(function (ProductVariantInterface $variant) {
            return $variant->isReorderable() === true;
        });
        return $this->reorderable = count($trackedVariants) > 0;
    }

We should also be able to check if a product is tracked or not by a similar logic – at least one of its variants must be trackable. The Phpspec example for this is straightforward as the two variants we’ve got are both trackable.

我们还应该能够检查是否通过类似的逻辑跟踪了产品–至少其中一个变体必须是可跟踪的。 Phpspec示例很简单，因为我们可以找到两个变体。

function it_recognizes_product_as_tracked_if_at_least_one_variant_is_tracked() {
        $this->isTracked()->shouldReturn(true);
    }

We’ll now run the spec and update the generated `isTracked()` method with:

现在，我们将运行规范并使用以下命令更新生成的`isTracked()`方法：

public function isTracked()
    {
        $variants = $this->getVariants();
        $trackedVariants = $variants->filter(
            function (ProductVariantInterface $variant) {
                return $variant->isTracked() === true;
            }
        );
    
        return $this->tracked = count($trackedVariants) > 0;
    }

All good. Perhaps we should add an example to make sure `isTracked()` returns `false` if no variant is tracked. Both variants in our `let()` method are already being tracked. However, if we pass in two variant variables with matching names as in the `let()` method, we can override the behavior of the objects in our new example.

都好。 也许我们应该添加一个示例，以确保如果未跟踪任何变体，则`isTracked()`返回`false` 。 `let()`方法中的两个变体都已被跟踪。 但是，如果像`let()`方法那样传入两个具有匹配名称的变量变量，则可以在新示例中覆盖对象的行为。

function it_recognizes_product_as_not_tracked_if_no_variant_is_tracked(
      VariantInterface $firstVariant,
      VariantInterface $secondVariant
    ) {
        $firstVariant->isTracked()->willReturn(false);
        $secondVariant->isTracked()->willReturn(false);
        $this->isTracked()->shouldReturn(false);
    }

We can also play around with the booleans somewhat. For example, if we change `$this->isTracked()->shouldReturn(false);` to `$this->isTracked()->shouldReturn(true);` , we get a message like:

我们还可以在一定程度上使用布尔值。 例如，如果我们更改`$this->isTracked()->shouldReturn(false);` 到`$this->isTracked()->shouldReturn(true);` ，我们收到如下消息：

AppBundle/Entity/Product
        recognizes product as not tracked if no variant is tracked
            expected true, but got false.

Let’s change it back to `false`, so we continue from all greens. That wraps up our tests for the `Product` and `ProductVariant` classes. There’s a couple of things we need later in `Product`, like a `getOnHold()` method which checks a similar method for its variants. We should end up with the class as follows:

让我们将其更改回`false` ，因此我们从所有绿色开始。 总结了我们对`Product`和`ProductVariant`类的测试。 我们稍后在`Product`需要做几件事，例如一个`getOnHold()`方法，该方法检查其变体的相似方法。 我们应该以如下形式结束该类：

<?php
    
    // src/AppBundle/Entity/Product.php
    
    namespace AppBundle\Entity;
    
    use Sylius\Component\Core\Model\Product as BaseProduct;
    use AppBundle\Entity\ProductVariantInterface as ProductVariantInterface;
    
    class Product extends BaseProduct implements ProductInterface
    {
        /**
         * @var int
         */
        protected $onHold = 0;
    
        /**
         * @var int
         */
        protected $onHand = 0;
    
        /**
         * @var bool
         */
        protected $tracked = false;
    
        /**
         * @var bool
         */
        protected $reorderable = false;
    
    
        public function isTracked()
        {
            $variants = $this->getVariants();
            $trackedVariants = $variants->filter(
                function (ProductVariantInterface $variant) {
                    return $variant->isTracked() === true;
                }
            );
    
            return $this->tracked = count($trackedVariants) > 0;
        }
    
        public function getOnHand()
        {
            $onHand = 0;
            foreach ($this->getVariants() as $variant) {
                if ($variant->isTracked() === true) {
                    $onHand += $variant->getOnHand();
                }
            }
    
            return $this->onHand = $onHand;
        }
    
        public function getOnHold()
        {
            $onHold = 0;
            foreach ($this->getVariants() as $variant) {
                if ($variant->isTracked()) {
                    $onHold += $variant->getOnHold();
                }
            }
    
            return $this->onHold = $onHold;
        }
    
        public function isReorderable()
        {
            $variants = $this->getVariants();
            $trackedVariants = $variants->filter(
                function (ProductVariantInterface $variant) {
                    return $variant->isReorderable() === true;
                }
            );
    
            return $this->reorderable = count($trackedVariants) > 0;
        }
    }

## 结论 **(**Conclusion**)** ##

We’ve now learned how to extend the core functionality of Sylius **the right way** – by thoroughly testing while we develop. We added some new features, allowed Phpspec to generate stubs for them, and made all tests turn from red to green before proceeding with our development.

现在，我们已经学习了如何以**正确的方式**扩展Sylius的核心功能-通过在开发过程中进行全面测试。 我们添加了一些新功能，允许Phpspec为它们生成存根，并在进行我们的开发之前使所有测试从红色变为绿色。

In the final part of this “Extending Sylius” series, we’ll work with Behat and test the visual output of the changes our features have caused. Stay tuned!

在“扩展Sylius”系列的最后一部分中，我们将与Behat一起工作，并测试功能引起的更改的直观输出。 敬请关注！

> 翻译自: [https://www.sitepoint.com/upgrading-sylius-tdd-way-exploring-phpspec/][https_www.sitepoint.com_upgrading-sylius-tdd-way-exploring-phpspec]

tdd:spock工作原理

[Christopher Pitt]: https://www.sitepoint.com/author/assertchris
[post on developing and testing new Sylius features]: https://www.sitepoint.com/sylius-and-cutting-your-teeth-on-tdd/
[PHPUnit]: https://www.sitepoint.com/tag/phpunit
[Phpspec]: https://www.sitepoint.com/tag/phpspec
[Behat]: https://www.sitepoint.com/tag/behat
[Sylius logo]: /images/20221123/c4e7e3feb74642bcacacabe033144563.png
[inventory management solution]: http://docs.sylius.org/en/latest/bundles/SyliusInventoryBundle/index.html
[Running Phpspec and getting confirmation for auto-creating a method]: /images/20221123/a50ecc9416934bb2a130d4d46c595c91.png
[Another offer to create a method]: /images/20221123/b571ee01089c460ebd576aed2119c05f.png
[Five passing tests]: /images/20221123/95ea349b6f5e42049cff307dac740bec.png
[https_www.sitepoint.com_upgrading-sylius-tdd-way-exploring-phpspec]: https://www.sitepoint.com/upgrading-sylius-tdd-way-exploring-phpspec/