I’m working on my own checkout system that uses Solidus under the hood. (Basically my own set of controllers and views that manipulate the Solidus models). I wanted to provide some feedback about the testing factories that come with Solidus, as I’ve been using them in my test suite and I’ve run into difficulties a few times. Generally the

Spree::Order

factory likes to create objects with a lot of extra data that’s not required for validity (which is discouraged ). Some examples: •

create(:order)

generates a Solidus

user

, but my checkout only uses guest checkouts. •

create(:order_with_line_items)

generates an order with a

bill_address

and

ship_address

, even though the order is still in the

cart

state. In the real world an order would never have addresses at this point in the checkout lifecycle, but all the test objects do. •

create(:order_with_line_items)

also generates a whole bunch of

Spree::ShippingWhatever

objects. My checkout has to interact with a third-party supplier to get shipping quotes, which then creates the necessary

Spree::ShippingMethod

objects. I’m still tracking down the best way to fix this, but I know I’m hitting a problem where my code expects a

Spree::ShippingCategory

with a name “Default” but my

:order_with_line_items

has a shipping method with a

Spree::ShippingCategory

with a name

"ShippingCategory #1"

. Generally it would be nice if some of these extra elements were split out into traits. If I could write eg.

create(:order_with_line_items, :with_addresses, :with_shipping)

to get the current object then I’d also be able to write

create(:order_with_line_items)

to get an order with just line items. Right now I’m defining my own factories that use Solidus’ factories as a base, and then undoing the associations/data that wouldn’t normally be found at that point in the checkout lifecycle.

I've thought about this issue before. One of the issues is that so many existing test suites use the factories that we're going to end up running afoul of Hyrum's Law if we change them significantly. People are certainly depending on the existing behaviours and changing them will be a pain for people. It'll break test suites across all our extensions in a way that's really annoying to deal with (because the test suites will need to work with versions before and after we make any of these changes). One possible solution I've considered is that deprecate all the existing factories and switch to a set of factories using

spree_

prefixes. Stores/extensions could move to the new set at their convenience without the difficulty of trying to make their test suites work with multiple different versions of the factories.

Hi guys, I've only just started playing around with Solidus, but the broken state of the test suite on a fresh install is pretty striking. The flakiness of the front-end specs aside, I'm confused as to how some of the deterministic failures have made it through to release. One example:

spec/system/checkout_spec.rb:272

fails in test setup with

Validation failed: ISO has already been taken

.

Spree::TestingSupport::OrderWalkthrough.up_to

wants to create a country with the default ISO of 'US'. Problem is, the country already exists because checkout_spec includes the

checkout setup

context. ISO uniqueness was specifically mentioned as a change in the last release, so how did this not get caught in the release process?