Support to use the acceptance test suite on customized stores

[DanieliMi]

This test suite is fantastic in that it already provides all the necessary fixtures, page objects, and other utilities needed to write tests for the store. However, it currently only works on clean installs with specific example (or default) data present. It would be incredibly useful if the suite allowed for more flexibility in configuring the default data being used. This would make it possible to run tests on customer projects that differ from a clean install.

Example

For instance, we have developed a plugin for one of our customers and would like to test it in both testing and staging environments. Unfortunately, in these environments, we cannot use some of the admin page objects because the required shipping method "Standard" is missing. This shipping method is queried in the following part of the code:

acceptance-test-suite/src/services/ShopwareDataHelpers.ts

Lines 112 to 127 in 19333ce

	export const getDefaultShippingMethodId = async (adminApiContext: AdminApiContext): Promise<string> => {
	const resp = await adminApiContext.post('search/shipping-method', {
	data: {
	limit: 1,
	filter: [{
	type: 'equals',
	field: 'name',
	value: 'Standard',
	}],
	},
	});
	const result = (await resp.json()) as { data: { id: string; active: boolean }[]; total: number };
	return result.data[0].id;
	};

To work around this, we currently have to completely overwrite some of the fixtures, which is not ideal. We would prefer to keep most of the suite logic intact and only override what is absolutely necessary.

Solution

It would be great to introduce a mechanism that allows us to configure the default data used in the fixtures. Ideally, this could be done in one of the following ways:

• Let us somehow configure the default data to be used in the fixtures.
• A way to extend the fixtures or overwrite only certain properties instead of having to completely overwrite them.

I am aware of Playwright’s extension system but extending a fixture is not a viable solution in our example since the data is loaded when the fixture is created and it will be created if we inject the original fixture.

Would you be open to such a change?

[pweyck]

First of all, thank you for the feedback 💙

One of the original design goals for the package was that it "just works" with an APP_URL and auth credentials and that's only possible if we don't expect any particular state. So it's in full alignment with what you're asking for. We try to reach this goal by creating most data instead of relying on existing one. But obviously there's some global/sales channel level config, that might differ from use case to use case.

We're still assuming some things about the shop:

• payment method is InvoicePayment
• shipping method is Standard
• EUR currency is available (system default is also added)
• en-GB language is available (system default is also added)
• de country is available
• you want to use the default Storefront theme

acceptance-test-suite/src/fixtures/DefaultSalesChannel.ts

Lines 52 to 59 in ba108ea

	language: getLanguageData('en-GB', AdminApiContext),
	currencyEUR: getCurrency('EUR', AdminApiContext),
	invoicePaymentMethodId: getPaymentMethodId(AdminApiContext),
	defaultShippingMethod: getDefaultShippingMethodId(AdminApiContext),
	getTaxId: getTaxId(AdminApiContext),
	deCountryId: getCountryId('de', AdminApiContext),
	enGBSnippetSetId: getSnippetSetId('en-GB', AdminApiContext),
	defaultThemeId: getThemeId('Storefront', AdminApiContext),

If we define all of those as separate fixtures, you could override them individually. Would that solve your problem?

Any contributions in that direction are very welcome

[DanieliMi]

Hi @pweyck, thank you for your Feedback. I think that solution would resolve the problem since we then can override the fixtures we need but leave the others as they are. I might even suggest to move all the methods from https://github.com/shopware/acceptance-test-suite/blob/ba108ea999e25e825c46ec308202b247d077c089/src/services/ShopwareDataHelpers.ts into Fixtures. Since then we still have all the default data as currently is but full control in case we need to change any of them it is possible. What do you think of that?

I'd be happy and try provide a PR with those changes. I am not very experienced with TypeScript and Playwright so I'd start with moving one method into a fixture and let you review it to see if it's the right approach.

[DanieliMi]

@pweyck I just created a draft PR #308. Could you have a look at it and see if it is what you had in mind? If so I will continue migrating the methods into fixtures.

I have tested the changes in one of our project and with the fixture it works like a charm! We can just override the new fixture with our custom shipping method and leave everything else as is.

[pweyck]

Looks good so far, thanks for the PR. I'd like to keep the helpers in general and only deprecate/remove the problematic ones.