Problem/Motivation

Convert the Commerce tests to use assert entity methods in CommerceMigrateTestTrait.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

quietone created an issue. See original summary.

quietone’s picture

Status: Active » Needs review
StatusFileSize
new5.75 KB
quietone’s picture

Status: Needs review » Postponed
quietone’s picture

StatusFileSize
new11.34 KB
new5.23 KB

Add assert entity tests for ProductType and ProductVariationType.

quietone’s picture

Status: Postponed » Needs review
StatusFileSize
new11.34 KB
new1.85 KB

Test wasn't finished properly.

Status: Needs review » Needs work

The last submitted patch, 5: 2894733-5.patch, failed testing. View results

quietone’s picture

Status: Needs work » Needs review
heddn’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll, +Novice
quietone’s picture

Status: Needs work » Needs review
StatusFileSize
new11.21 KB

Reroll

joshmiller’s picture

Issue tags: -Needs reroll
heddn’s picture

Status: Needs review » Reviewed & tested by the community

I wonder if using the data provider pattern would make these tests easier to read and maintain. I mean, we're in there already updating these tests. Why not go all the way. If that is out of scope, this is RTBC and we can do that in a follow-up. Otherwise, NW.

heddn’s picture

Status: Reviewed & tested by the community » Needs work

Gonna work on the data provider changes.

heddn’s picture

Status: Needs work » Needs review
Issue tags: -Novice
StatusFileSize
new30.2 KB
new33.93 KB

There's going to be a failed test here (I hope). I think we need to look at the product migration a little. The product id for a variation loaded from the product is pointed to another product, not the product it was referenced from.

I also cleaned-up the test trait, because the DX of the parameter names was difficult to read.

Status: Needs review » Needs work

The last submitted patch, 13: 2894733-13.patch, failed testing. View results

quietone’s picture

I wonder if using the data provider pattern would make these tests easier to read and maintain. I

I would have preferred that to be a follow up. I see the advantages and like them. But one drawback I see is that ProductTypeTest and ProductVariationTest will take twice as long to run.

I also cleaned-up the test trait, because the DX of the parameter names was difficult to read.

Yes, the $expected on all the parameters is bulky. But I am so used to now that is just what I do.

I think we need to look at the product migration a little.

Whoa, odd things happening here. Some debugging and I see that after these migrations

    $this->executeMigrations([
      'd7_user_role',
      'd7_user',
      'd7_product_type',
      'd7_product',
      'd7_product_display_type',
    ]);

there aren't any products, the commerce_product table is empty.

After those are run, 'd7_product_display' is run and that creates 20 of the 84 products. The first one has an id 15, which is id 1 in the source.
]);

heddn’s picture

Status: Needs work » Reviewed & tested by the community

Committing #9 and move the refactor to a follow-up: #2899321: Refactor Commerce Product and ProfileBilling tests

  • heddn committed f8d9af1 on 8.x-2.x
    Issue #2894733 by quietone, heddn: Convert Commerce Product and...
heddn’s picture

Status: Reviewed & tested by the community » Fixed
quietone’s picture

@heddn, thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.