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

最新推荐文章于 2024-07-12 16:03:26 发布

culi4814

最新推荐文章于 2024-07-12 16:03:26 发布

阅读量189

点赞数

文章标签： java python 数据库 php web

原文链接：https://www.sitepoint.com/upgrading-sylius-tdd-way-exploring-behat/

版权

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内容达到最佳状态！

Last time, we developed some new features on top of Sylius’ core to indicate which products and their variants are low on stock and need replenishing. Now, we move on to seeing our changes in the UI, which means we will need to do a bit of StoryBDD testing.

上一次，我们在Sylius的核心之上开发了一些新功能，以指示哪些产品及其变型产品库存不足，需要补充。现在，我们继续查看UI中的更改，这意味着我们将需要进行一些StoryBDD测试。

When browsing the list of products, we want to see a new column called Inventory which will hold a sum of all available tracked variants’ stock amounts.

浏览产品列表时，我们希望看到一个名为“ Inventory的新列，其中将包含所有可用的跟踪变体的库存量之和。

编写StoryBDD测试 (Writing StoryBDD Tests)

Behat is the tool we want to use here. After making sure Behat is working well by running any feature from the Sylius package, we create a new features/product/managing_products/browsing_products_with_inventory.feature file with the following definition:

Behat是我们要在这里使用的工具。通过运行Sylius软件包中的任何功能确保Behat正常运行后，我们使用以下定义创建一个新的features/product/managing_products/browsing_products_with_inventory.feature文件：

@managing_inventory
Feature: Browsing products with inventory
    In order to manage my shop merchandise
    As an Administrator
    I want to be able to browse products

    Background:
        Given the store operates on a single channel in "United States"
        And the store has a product "Kubus"
        And it comes in the following variations:
            | name          | price     |
            | Kubus Banana  | $2.00     |
            | Kubus Carrot  | $2.00     |
        And there are 3 units of "Kubus Banana" variant of product "Kubus" available in the inventory
        And there are 5 units of "Kubus Carrot" variant of product "Kubus" available in the inventory
        And I am logged in as an administrator

    @ui
    Scenario: Browsing defined products with inventory
        Given the "Kubus Banana" product variant is tracked by the inventory
        And the "Kubus Carrot" product variant is tracked by the inventory
        When I want to browse products
        Then I should see that the product "Kubus" has 8 on hand quantity

Again, we describe the make-up of our test product, stating the name, price and available stock of the two variants. If we run this feature, we see a list of paths for available contexts. We aren’t interested in any of them, but we also get a hint, so we select None.

再次，我们描述测试产品的组成，并说明两种型号的名称，价格和可用库存。如果运行此功能，则会看到可用上下文的路径列表。我们对它们都不感兴趣，但是我们也会得到提示，因此我们选择None 。

php bin/behat features/product/managing_products/browsing_products_with_inventory.feature

--- Use --snippets-for CLI option to generate snippets for following ui_managing_inventory suite steps:

    When I want to browse products
    Then I should see that the product "Kubus" has 18 on hand quantity

We create our context in src/Sylius/Behat/Context/Ui/Admin/ManagingProductsInventoryContext.php and add this:

我们在src/Sylius/Behat/Context/Ui/Admin/ManagingProductsInventoryContext.php创建上下文，并添加以下内容：

<?php

// src/Sylius/Behat/Context/Ui/Admin/ManagingProductsInventoryContext.php

namespace Sylius\Behat\Context\Ui\Admin;

use Behat\Behat\Context\Context;

class ManagingProductsInventoryContext implements Context
{
}

Running the feature again doesn’t seem to help as we get the same list of contexts as before. That’s because Sylius doesn’t know anything about our class. We need to configure a service for our context together with what Sylius has in src/Sylius/Behat/Resources/config/services/contexts/ui.xml. We now search for managing_products and add this below it:

再次运行该功能似乎无济于事，因为我们获得了与以前相同的上下文列表。那是因为Sylius对我们班一无所知。我们需要为上下文配置服务，以及Sylius在src/Sylius/Behat/Resources/config/services/contexts/ui.xml 。现在，我们搜索managing_products ，并将其添加到下面：

<service id="sylius.behat.context.ui.admin.managing_products_inventory" class="Sylius\Behat\Context\Ui\Admin\ManagingProductsInventoryContext">
    <argument type="service" id="sylius.behat.page.admin.product.index" />
    <tag name="fob.context_service" />
</service>

Let’s add our sylius.behat.context.ui.admin.managing_products_inventory service (that’s the id in ui.xml) to the context services for ui_managing_inventory suites in src/Sylius/Behat/Resources/config/suites/ui/inventory/managing_inventory.yml.

让我们添加sylius.behat.context.ui.admin.managing_products_inventory服务(这是id在ui.xml )上下文服务ui_managing_inventory套房src/Sylius/Behat/Resources/config/suites/ui/inventory/managing_inventory.yml 。

We may need to clear the cache. If we run the feature, we now get an option to select Sylius\Behat\Context\Ui\Admin\ManagingProductsInventoryContext. We then get:

我们可能需要清除缓存。如果运行该功能，我们现在可以选择Sylius\Behat\Context\Ui\Admin\ManagingProductsInventoryContext 。然后我们得到：

--- Sylius\Behat\Context\Ui\Admin\ManagingProductsInventoryContext has missing steps. Define them with these snippets:

    /**
     * @When I want to browse products
     */
    public function iWantToBrowseProducts()
    {
        throw new PendingException();
    }

    /**
     * @Then I should see that the product :arg1 has :arg2 on hand quantity
     */
    public function iShouldSeeThatTheProductHasOnHandQuantity($arg1, $arg2)
    {
        throw new PendingException();
    }

We can just copy and paste the snippets into the context class we created. Out of curiosity we may import PendingException just to see the output. Let’s add use Behat\Behat\Tester\Exception\PendingException; to the top of the class and re-run the feature.

我们可以仅将片段复制并粘贴到我们创建的上下文类中。出于好奇，我们可能会导入PendingException只是为了查看输出。让我们添加use Behat\Behat\Tester\Exception\PendingException; 移至课程顶部，然后重新运行功能。

We get an error:

我们收到一个错误：

An exception occured in driver: SQLSTATE[HY000] [1049] Unknown database 'xxxx_test' (Doctrine\DBAL\Exception\ConnectionException)

That’s because we haven’t created the test database. These two commands will do that for us now.

那是因为我们还没有创建测试数据库。这两个命令现在将为我们完成此操作。

php bin/console doctrine:database:create --env=test
php bin/console doctrine:schema:create --env=test

If you’d created the test database before altering the product_variant table for reorder_level column in the previous post, you may be getting an error:

如果您在更改上一篇文章中的reorder_level列的product_variant表之前创建了测试数据库，则可能会收到错误消息：

Column not found: 1054 Unknown column 'reorder_level' in 'field list'

Then, let’s update the test database with:

然后，使用以下命令更新测试数据库：

php bin/console doctrine:schema:update --env=test --force

The feature can now be run and you can see this in the middle of the output:

现在可以运行该功能，您可以在输出的中间看到它：

When I want to browse products
      TODO: write pending definition

The “TODO: write pending definition” is the PendingException message. Going back to our ManagingProductsInventoryContext, something else is missing. The service we configured had an argument: <argument type="service" id="sylius.behat.page.admin.product.index" />; but this isn’t in our class yet.

“ TODO：写待定定义”是PendingException消息。回到我们的ManagingProductsInventoryContext ，其他东西丢失了。我们配置的服务有一个参数： <argument type="service" id="sylius.behat.page.admin.product.index" /> ; 但这还不在我们班上。

The sylius.behat.page.admin.product.index service is for visiting the index page of product management. If we look in src/Sylius/Behat/Resources/config/services/pages/admin/product.xml (found by searching for where sylius.behat.page.admin.product.index is defined) we see that the class is Sylius\Behat\Page\Admin\Product\IndexPage. We need to inject the interface into our context class.

sylius.behat.page.admin.product.index服务用于访问产品管理的索引页面。如果我们查看src/Sylius/Behat/Resources/config/services/pages/admin/product.xml (通过搜索定义sylius.behat.page.admin.product.index的位置sylius.behat.page.admin.product.index )，我们会看到该类是Sylius\Behat\Page\Admin\Product\IndexPage 。我们需要将接口注入到上下文类中。

Also in the iWantToBrowseProducts() method, we can now visit the index page by calling the right method from our instance of IndexPageInterface. So ourManagingProductsInventoryContext.php should look like this:

另外，在iWantToBrowseProducts()方法，我们现在可以通过调用我们的情况下正确的方法访问索引页IndexPageInterface 。因此，我们的ManagingProductsInventoryContext.php应该如下所示：

<?php

// src/Sylius/Behat/Context/Ui/Admin/ManagingProductsInventoryContext.php

use Behat\Behat\Context\Context;
use Sylius\Behat\Page\Admin\Product\IndexPageInterface;
use Behat\Behat\Tester\Exception\PendingException;

class ManagingProductsInventoryContext implements Context
{
    /**
     * @var IndexPageInterface
     */
    private $indexPage;

    /**
     * @param IndexPageInterface $indexPage
     */
    public function __construct(IndexPageInterface $indexPage)
    {
        $this->indexPage = $indexPage;
    }

    /**
     * @When I want to browse products
     */
    public function iWantToBrowseProducts()
    {
        $this->indexPage->open();
    }

    /**
     * @Then I should see that the product :arg1 has :arg2 on hand quantity
     */
    public function iShouldSeeThatTheProductHasOnHandQuantity($arg1, $arg2)
    {
        throw new PendingException();
    }
}

It passes and we receive a prompt for the other missing definition:

它通过了，我们提示您输入另一个缺少的定义：

Then I should see that the product "Kubus" has 18 on hand quantity
      TODO: write pending definition

First we want to change the argument names so that we know what they refer to – $product, and $quantity. Type-hinting $product is also a good idea. Sylius has a lot of generic methods we can call to check that we’ve got a column called “inventory” and we have the right number of available items for our test product. This is what the iShouldSeeThatTheProductHasOnHandQuantity() method should look like now:

首先，我们要更改参数名称，以便我们知道它们所指的内容- $product和$quantity 。提示$product也是一个好主意。 Sylius有很多通用方法，可以调用它们来检查是否有一个名为“库存”的列，并且我们有正确数量的可用于测试产品的项目。这就是iShouldSeeThatTheProductHasOnHandQuantity()方法现在的样子：

/**
 * @Then I should see that the product :product has :quantity on hand quantity
 */
public function iShouldSeeThatTheProductHasOnHandQuantity(Product $product, $quantity)
{
    Assert::notNull($this->indexPage->getColumnFields('inventory'));
    Assert::true($this->indexPage->isSingleResourceOnPage([
      'name' => $product->getName(),
      'inventory' => sprintf('%d Available on hand', $quantity),
    ]));
}

We’ve introduced two classes: Assert and Product. Let’s import them with:

我们介绍了两个类： Assert和Product 。让我们导入它们：

use Webmozart\Assert\Assert;
use AppBundle\Entity\Product;

At the same time, you may remove the PendingException import that’s no longer in use.

同时，您可以删除不再使用的PendingException导入。

Now the scenario fails with a different error message:

现在，该方案失败，并显示其他错误消息：

Then I should see that the product "Kubus" has 18 on hand quantity
      Column with name "inventory" not found! (InvalidArgumentException)

Behat has opened the product listing page, and there’s no Inventory column. Let’s add it. Lists are usually displayed with the Sylius Grid component. The SyliusGridBundle uses YAML configuration files that describe the structure of a given grid. For the admin section, these are located in src/Sylius/Bundle/AdminBundle/Resources/config/grids/. We only need to replicate what’s in the product_variant.yml for our “inventory” column in the product.yml.

Behat已打开产品列表页面，并且没有“ Inventory列。让我们添加它。列表通常与Sylius网格组件一起显示。 SyliusGridBundle使用YAML配置文件来描述给定网格的结构。对于admin部分，它们位于src/Sylius/Bundle/AdminBundle/Resources/config/grids/ 。我们只需要为product.yml中的“库存”列复制product_variant.yml中的内容。

inventory:
    type: twig
    path: .
    label: sylius.ui.inventory
    options:
        template: "@SyliusAdmin/ProductVariant/Grid/Field/inventory.html.twig"

Most importantly, we need to override product.yml properly. We copy src/Sylius/Bundle/AdminBundle/Resources/config/grids/product.yml to app/Resources/SyliusAdminBundle/config/grids/product.yml. We add the inventory column configuration above to it, maybe after “name”. After clearing caches and running the tests, everything should pass.

最重要的是，我们需要正确覆盖product.yml 。我们将src/Sylius/Bundle/AdminBundle/Resources/config/grids/product.yml复制到app/Resources/SyliusAdminBundle/config/grids/product.yml 。我们在上面添加了清单栏配置，也许在“名称”之后。清除缓存并运行测试后，一切都应该通过。

Now, we want to modify inventory.html.twig with our reorder level logic so that we can indicate when stock is getting low. That will take care of both Product and ProductVariant grids since their inventory field shares the same template. Let’s copy src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/Grid/Field/inventory.html.twig to app/Resources/SyliusAdminBundle/views/ProductVariant/Grid/Field/inventory.html.twig and replace the contents with:

现在，我们要使用重新订购级别逻辑来修改inventory.html.twig ，以便我们可以指示何时库存下降。这将照顾到Product和ProductVariant网格，因为它们的库存字段共享相同的模板。让我们将src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/Grid/Field/inventory.html.twig app/Resources/SyliusAdminBundle/views/ProductVariant/Grid/Field/inventory.html.twig到app/Resources/SyliusAdminBundle/views/ProductVariant/Grid/Field/inventory.html.twig并将内容替换为：

{% if data.isTracked %}
    {% if data.onHand > 0 %}
        {% set classes = (data.isReorderable) ? 'yellow' : 'green' %}
    {% else %}
        {% set classes = 'red' %}
    {% endif %}
<div class="ui {{ classes }} icon label">
    <i class="cube icon"></i>
    <span class="onHand" data-product-variant-id="{{ data.id }}">{{ data.onHand }}</span> {{ 'sylius.ui.available_on_hand'|trans }}
    {% if data.onHold > 0 %}
    <div class="detail">
        <span class="onHold" data-product-variant-id="{{ data.id }}">{{ data.onHold }}</span> {{ 'sylius.ui.reserved'|trans }}
    </div>
    {% endif %}
</div>
{% else %}
    <span class="ui red label">
        <i class="remove icon"></i>
        {{ 'sylius.ui.not_tracked'|trans }}
    </span>
{% endif %}

After we clear the cache, we can view the list from the admin UI. Let’s edit some product variants of a product, change the inventory level, and view the expected results. If any variant has 5 or fewer tracked items in stock, there’ll be a third color (yellow) to indicate that stock is at reorder level for that item. Everything’s all right except we have no way of changing the reorder level. We’ll round this up with how to customize the product variant form so we can change it. There are 3 important words to remember here – class, service, and configuration.

清除缓存后，我们可以从管理界面查看列表。让我们编辑产品的某些产品变型，更改库存水平，并查看预期结果。如果任何变体中有5个或更少的跟踪物料，则将有第三种颜色(黄色)指示该物料的库存处于重新订购级别。一切正常，除了我们无法更改重新订购级别。我们将围绕如何自定义产品变体形式进行总结，以便我们进行更改。这里要记住3个重要的单词-类，服务和配置。

自定义ProductVariant表单 (Customize ProductVariant Form)

We customize a form by extending a form class. Symfony uses a service container to standardize how objects are constructed in an application. If only we could see a list of services… perhaps we could find some information about the right one to work with? Let’s try this:

我们通过扩展表单类来自定义表单。 Symfony使用服务容器来标准化应用程序中对象的构造方式。如果仅我们可以看到服务列表...也许我们可以找到有关合适的服务的一些信息？让我们尝试一下：

php bin/console debug:container product_variant

You get a list of service ids and going through them, you’ll see one with “sylius.form.type.product_variant” which looks like what we need. Select that and note that the class we need to extend is Sylius\Bundle\ProductBundle\Form\Type\ProductVariantType.

您将获得一份服务ID列表，并进行遍历，您将看到一个带有“ sylius.form.type.product_variant”的文件，看起来像我们所需要的。选择它，并注意我们需要扩展的类是Sylius\Bundle\ProductBundle\Form\Type\ProductVariantType 。

创建服务 (Create a Service)

Let’s create src/AppBundle/Resources/config/services.yml and add this:

让我们创建src/AppBundle/Resources/config/services.yml并添加以下内容：

services:
    app.form.extension.type.product_variant:
        class: AppBundle\Form\Type\Extension\ProductVariantTypeExtension
        tags:
            - { name: form.type_extension, extended_type: Sylius\Bundle\ProductBundle\Form\Type\ProductVariantType }

建立课程 (Create a Class)

The service defined above is for a class. Let’s create src/AppBundle/Form/Type/Extension/ProductVariantTypeExtension.php, and add this:

上面定义的服务是针对一个类的。让我们创建src/AppBundle/Form/Type/Extension/ProductVariantTypeExtension.php ，并添加以下内容：

<?php

// src/AppBundle/Form/Type/Extension/ProductVariantTypeExtension.php

namespace AppBundle\Form\Type\Extension;

use Sylius\Bundle\ProductBundle\Form\Type\ProductVariantType;
use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\FormBuilderInterface;

class ProductVariantTypeExtension extends AbstractTypeExtension
{
    /**
     * {@inheritdoc}
     */
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->add(
          'reorderLevel',
          TextType::class,
          [
            'required' => false,
            'label' => 'sylius.form.variant.reorder_level',
          ]
        );
    }

    /**
     * {@inheritdoc}
     */
    public function getExtendedType()
    {
        return ProductVariantType::class;
    }
}

The label requires a messages configuration file. We’ll create app/Resources/SyliusAdminBundle/translations/messages.en.yml and add this:

标签需要消息配置文件。我们将创建app/Resources/SyliusAdminBundle/translations/messages.en.yml并添加以下内容：

sylius:
    form:
        variant:
            reorder_level: 'Reorder level'

We can see the hierarchy of the keys in the name – sylius.form.variant.reorder_level. Let’s inform Sylius about the service in app/config/config.yml, by adding this under imports:

我们可以在名称sylius.form.variant.reorder_level看到键的层次结构。通过在imports下添加以下内容，让app/config/config.yml的服务：

- { resource: "@AppBundle/Resources/config/services.yml"}

覆盖模板 (Overriding a Template)

Now, how do we find the template to override? We go to a product variant list and edit one of them, so that we can identify the template used to display the form. Across the bottom of the page is the Web Debug Toolbar and Profiler.

现在，我们如何找到要覆盖的模板？我们转到产品变型列表并编辑其中一个，以便我们可以标识用于显示表单的模板。页面底部是Web调试工具栏和Profiler。

On the left is the HTTP Status Code and next to it is the Route name. Clicking on the route name shows the profiler. There’s a lot of data about the Request among which is the Request Attributes section, with the following keys: _controller, _route, _route_params and id. The Value column for _sylius shows an arrow, indicating an array. Clicking on it expands the array with “section”, “template”, “redirect”, “permission” and “vars” keys. The value of “template” is SyliusAdminBundle:Crud:update.html.twig which is located at src/Sylius/Bundle/AdminBundle/Resources/views/Crud/update.html.twig.

左侧是HTTP状态代码，其旁边是路由名称。单击路径名称将显示分析器。关于请求的数据很多，其中包括“请求属性”部分，其中包含以下键： _controller ， _route ， _route_params和id 。 _sylius “值”列显示一个箭头，指示一个数组。单击它可以使用“ section”，“ template”，“ redirect”，“ permission”和“ vars”键扩展数组。 “模板”的值为SyliusAdminBundle:Crud:update.html.twig ，位于src/Sylius/Bundle/AdminBundle/Resources/views/Crud/update.html.twig 。

Looking at update.html.twig, among a number of includes is this one – {% include '@SyliusAdmin/Crud/Update/_content.html.twig' %}. Again, that is found at src/Sylius/Bundle/AdminBundle/Resources/views/Crud/Update/_content.html.twig. There’s nothing interesting in the file. Dead end!

查看update.html.twig ，其中包括- {% include '@SyliusAdmin/Crud/Update/_content.html.twig' %} 。同样，可以在src/Sylius/Bundle/AdminBundle/Resources/views/Crud/Update/_content.html.twig 。文件中没有任何有趣的东西。死路！

If we go back to the Request Attributes and expand _vars and then the templates key, we see the @SyliusAdmin/ProductVariant/_form.html.twig which we find in src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/_form.html.twig. In _form.html.twig, there’s a Twig function knp_menu_get(). Menu? What menu? We’re looking for a form. This is a different type of page, built with different templates. Looking back at the page itself, we notice two tabs – “Details” and “Taxes”. Tabs and menus do go together so, maybe we’re on the right track.

如果返回到“请求属性”并依次展开_vars和templates键， @SyliusAdmin/ProductVariant/_form.html.twig看到@SyliusAdmin/ProductVariant/_form.html.twig ，该文件位于src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/_form.html.twig 。在_form.html.twig ，有一个Twig函数knp_menu_get() 。菜单？什么菜单？我们正在寻找一个表格。这是另一种类型的页面，具有不同的模板。回顾页面本身，我们注意到两个选项卡-“详细信息”和“税收”。选项卡和菜单确实在一起，所以也许我们走在正确的轨道上。

Returning to the list of services we saw with php bin/console debug:container product_variant, we may be able to find one with “menu” and “product_variant”. Indeed, there’s one: sylius.admin.menu_builder.product_variant_form which when we debug, gives us some interesting information:

返回我们在php bin/console debug:container product_variant看到的服务列表，我们也许可以找到带有“ menu”和“ product_variant”的服务。确实，有一个： sylius.admin.menu_builder.product_variant_form ，当我们调试时，它会提供一些有趣的信息：

For the Tags option, the value is knp_menu.menu_builder (method: createMenu, alias: sylius.admin.product_variant_form). That alias is the first parameter of the knp_menu_get() method in our _form.html.twig template. We’re definitely on the right track.

对于“标签”选项，该值为knp_menu.menu_builder (method: createMenu, alias: sylius.admin.product_variant_form) 。该别名是_form.html.twig模板中knp_menu_get()方法的第一个参数。我们绝对在正确的轨道上。

From the debugging information above, we also know that the Sylius\Bundle\AdminBundle\Menu\ProductVariantFormMenuBuilder class is responsible for the form. Opening up the class and looking at the createMenu() method we see our details and taxes tabs with their respective templates – @SyliusAdmin/ProductVariant/Tab/_details.html.twig and @SyliusAdmin/ProductVariant/Tab/_taxes.html.twig. We can confirm that we’ve found the right template to override by checking src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/Tab/_details.html.twig.

从上面的调试信息中，我们还知道Sylius\Bundle\AdminBundle\Menu\ProductVariantFormMenuBuilder类负责该表单。开放类和看createMenu()我们看到我们的方法details和taxes卡口与各自的模板- @SyliusAdmin/ProductVariant/Tab/_details.html.twig和@SyliusAdmin/ProductVariant/Tab/_taxes.html.twig 。我们可以通过检查src/Sylius/Bundle/AdminBundle/Resources/views/ProductVariant/Tab/_details.html.twig来确认已找到要覆盖的正确模板。

Let’s copy the file to app/Resources/SyliusAdminBundle/views/ProductVariant/Tab/_details.html.twig. Finding the inventory section, we add the new field {{ form_row(form.reorderLevel) }} anywhere. I put mine between {{ form_row(form.onHand) }} and {{ form_row(form.tracked) }}. If we go back to the product variant form, the textfield should be right there. We can change the default to any number, and save the file.

让我们将文件复制到app/Resources/SyliusAdminBundle/views/ProductVariant/Tab/_details.html.twig 。找到库存部分，我们在任何地方添加新字段{{ form_row(form.reorderLevel) }} 。我把我的放在{{ form_row(form.onHand) }}和{{ form_row(form.tracked) }} 。如果我们回到产品变体形式，则文本字段应该就在此处。我们可以将默认值更改为任何数字，然后保存文件。

结论 (Conclusion)

Our series’ final part is complete – we were able to add new functionality to Sylius without incurring long-term technical debt, and without sacrificing the app’s 100% test coverage. We covered all types of testing available in this e-commerce framework, and used its best practices to their full potential.

我们系列的最后一部分已经完成–我们能够为Sylius添加新功能，而不会招致长期的技术负担，也不会牺牲该应用程序的100％测试覆盖率。我们介绍了此电子商务框架中可用的所有类型的测试，并充分利用了其最佳实践。

In this part in particular, we’ve looked at writing SpecBDD tests into a bit more detail and how to overwrite Sylius models and forms. There’ll be different and more interesting ways of achieving the same goals. Let us know your take on some of them.

特别是在这一部分中，我们已经研究了如何编写更加详细的SpecBDD测试以及如何覆盖Sylius模型和形式。实现相同目标的方式会有所不同，并且会更加有趣。让我们知道您对其中的一些看法。

Are you using Sylius yet? Why/why not? What are some pitfalls you see in our approaches? Let’s discuss!

您正在使用Sylius吗？为什么/为什么不呢？您在我们的方法中看到哪些陷阱？让我们讨论！

翻译自: https://www.sitepoint.com/upgrading-sylius-tdd-way-exploring-behat/

tdd:spock工作原理

culi4814

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
tdd:spock工作原理_以TDD方式升级Sylius：探索Behat

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的同...
复制链接

扫一扫