Spryker Documentation

TS linter

Mon, 06 Jul 2026 11:41:35 +0000

{% info_block warningBox "No longer supported" %} Since the `202307.0` release, this tool is no longer supported and has been replaced by `ESLint`. To migrate to `ESLint`, follow [Migration guide - Switch from TSLint to ESLint](/docs/dg/dev/upgrade-and-migrate/migrate-from-tslint-to-eslint.html). {% endinfo_block %} *TS Linter* allows you to find and fix code style mistakes. It helps a team follow the same standards and make code more readable. To analyze and fix files, [TSLint](https://palantir.github.io/tslint/) is used. ## Installation For details about how to install the TS Linter for your project, see the [TS Linter integration file](/docs/dg/dev/integrate-and-configure/integrate-development-tools/integrate-ts-linter.html). ## Using TS Linter To execute the TS Linter, do the following: 1. Install the Node.js modules: ```bash npm ci ``` 2. Execute the TS Linter in: - validation mode: ```bash npm run yves:tslint ``` - fix mode: ```bash npm run yves:tslint:fix ``` ## TS Linter config The config for tslint resides in `/tslint.json`. To redefine the path for the config, adjust `/frontend/libs/tslint.js` and use other [rules](https://palantir.github.io/tslint/rules/) for the TS Linter. {% info_block infoBox %} The TS Linter rules related to formatting aren't included in `tslint.json` to avoid duplication with the [Prettier rules](https://www.npmjs.com/package/@spryker/frontend-config.prettier). {% endinfo_block %} ## CI checks and pre-commit hook The TS Linter is integrated into: - Pre-commit hooks. The function that executes TS Linter before the commit resides in `/.githook` ```text - GitHook\Command\FileCommand\PreCommit\TsLintCommand ``` - Travis. Command to run the TS Linter is integrated into `.travis.yml` ```yml - node ./frontend/libs/tslint --format stylish ``` {% info_block warningBox "Important" %} If you commit without the pre-commit hooks execution, you should run the TS Linter manually to avoid issues with CI. {% endinfo_block %}

Test framework

Mon, 06 Jul 2026 11:41:35 +0000

To easily test every aspect of Spryker and the code you write, Spryker uses the [Codeception testing framework](https://codeception.com/) and [PHPUnit](https://phpunit.de/). {% info_block infoBox %} We strongly recommend reading the documentation of both frameworks to get the best out of your tests. {% endinfo_block %} Codeception offers many handy things to write better and cleaner tests. Many solutions this framework has are built on top of PHPUnit. In the next articles, we will only reference Codeception even if these features are available in PHPUnit as well. On top of Codeception, we have built the [Testify](https://github.com/spryker/testify/) module, which provides many handy helpers. See [Testify](/docs/dg/dev/guidelines/testing-guidelines/testify.html) for more details on Testify itself, and [Testify Helpers](/docs/dg/dev/guidelines/testing-guidelines/test-helpers/test-helpers.html#testify-helpers) for details on the existing Testify helpers. ## Basic test setup To start running tests, you require a single `codeception.yml` file. Configuration provided in this file is used by default when executing the [vendor/bin/codecept run](#console-commands) command. This file, along with others, is included in the default Spryker installation and should be regarded as a starting point for your tests. Here is an example of the `codeception.yml` file: ```yaml namespace: PyzTest actor: Tester include: # This will include all codeception.yml's that can be found in the defined path - tests/PyzTest/*/* ... ``` ## Configuration The `codeception.yml` file at the root of your project is the main entry point for your tests. In this file, you define the basic configuration for your test suite. In this file, you can include other `codeception.yml` files to organize your tests better. Example: ```yml namespace: PyzTest actor: Tester include: - tests/PyzTest/*/* ... ``` For more information, see [Codeception configuration documentation](https://codeception.com/docs/reference/Configuration). {% info_block infoBox "Environment variables" %} You can specify `.env` files with environment variables in the `codeception.yml` file. The environment variables help configure your system for specific conditions. For example, they can define the store under which tests should be executed: ```yml params: - .env - .env.store-a.testing ``` {% endinfo_block %} ## Separating tests In numerous scenarios, you will need to improve your test setup by separating it into logical groups. By default, all test groups are located in `tests/Pyz`. The structure of items within this directory mirrors that of the `src` code: ```text tests/ -- Pyz/ ---- Glue/ ---- Shared/ ---- Yves/ ---- Zed/ ``` This structure is foundational in nearly all Spryker projects. All of the tests inside those directories are executed based on the configuration in the root `codeception.yml` file. ### Separating tests by namespace Especially in the development environment, it often makes sense to separate tests by their application namespace. This approach lets you, for example, to run only Zed-related tests. To separate tests by namespaces, place the `codeception.yml` file into the `tests/Pyz/Zed` directory. Here is an example of the `codeception.yml` file illustrating namespace-based separation: ```yml namespace: PyzTest actor: Tester include: # This will include all codeception.yml's that can be found in the defined path for this specific application namespace - tests/PyzTest/Zed/* ... ``` ### Separating tests by stores Imagine you have a large code base, and you use stores to implement additional or different behavior from the standard module. Suppose you have 10 thousand tests that are testing all your code, but you wish to execute tests for a particular store. In this situation, there's no need to execute all tests twice—once for the default store and once for each individual store. Instead, you can execute your test suite once for the default store and then execute tests for the specific stores you require:

You can achieve this by having separated `codeception.yml` files for the default store and for any other store. As you can see, there are many ways to leverage Codeception configuration files to achieve fine-grained or coarse-grained groups based on your testing needs. ## Console commands There are many console commands provided from Codeception, but the most used ones are: - `vendor/bin/codecept build` - generates classes - `vendor/bin/codecept run` - executes all your tests For information on other Codeception console commands, run `vendor/bin/codecept list`. See [Executing Tests](/docs/dg/dev/guidelines/testing-guidelines/executing-tests/executing-tests.html) for details on some commands. ## Testing with Spryker On top of Codeception, we have added a basic infrastructure for tests. We have divided our tests by the applications, and for the layer we test. Thus, the organization of tests in most cases looks like this: - `tests/OrganizationTest/Application/Module/Communication` - for example, controller or plugin tests. - `tests/OrganizationTest/Application/Module/Presentation` - for example, testing pages with JavaScript. - `tests/OrganizationTest/Application/Module/Business` - for example, testing facades or models. The **Communication** suite can contain unit and functional tests. The controller tests can be used to test like a user that interacts with the browser but without the overhead of the GUI rendering. This suite should be used for all tests that do not need JavaScript. The **Business** suite can contain unit and functional tests. The facade test is one kind of an API test approach. For more information, see [Test API](/docs/dg/dev/guidelines/testing-guidelines/testing-best-practices/best-practices-for-effective-testing.html#api-tests). The **Presentation** suite contains functional tests that can be used to interact with a headless browser. These tests should be used when you have JavaScript on the page under test. All test classes follow the exact same path as the class under test, except that tests live in the `tests` directory, and the organization part of the namespace is suffixed with `Test`. For example, `tests/PyzTest/*`. For details on the `tests` directory structure, see [Directory Structure](/docs/dg/dev/guidelines/testing-guidelines/setting-up-tests.html#directory-structure). Each test suite contains a `codeception.yml`configuration file. This file includes, for example, [helpers](/docs/dg/dev/guidelines/testing-guidelines/test-helpers/test-helpers.html) that are enabled for the current suite. ## Next step [Set up an organization of your tests](/docs/dg/dev/guidelines/testing-guidelines/setting-up-tests.html)

Spryker Marketplace

Mon, 06 Jul 2026 11:41:35 +0000

In this section, you will find all the information about Spryker Marketplace and how to start developing one. If you are new to Spryker, first see our [Intro to Spryker](/docs/about/all/about-spryker.html). ## Overview of Spryker Marketplace To learn what Spryker Marketplace is, read the following documents: - [Marketplace concept](/docs/about/all/spryker-marketplace/marketplace-concept.html) - [Marketplace personas](/docs/about/all/spryker-marketplace/marketplace-personas.html) - [Back Office for Marketplace Operator](/docs/about/all/spryker-marketplace/back-office-for-marketplace-operator.html) - [Marketplace Storefront](/docs/about/all/spryker-marketplace/marketplace-storefront.html) - [Merchant Portal](/docs/about/all/spryker-marketplace/marketplace-storefront.html) ## First steps with a Spryker Marketplace For new projects, we provide [B2C](/docs/about/all/spryker-marketplace/marketplace-b2c-suite.html) and [B2B Demo Marketplace](/docs/about/all/spryker-marketplace/marketplace-b2b-suite.html) templates, which are a great starting point. Even if you don't need marketplace features at first, but you are going to use them in the future, the Demo Marketplaces are still the best starting point. You can just ignore the marketplace features until you actually want to use them. To learn how to install B2C or B2B Demo Marketplace, see [Set up Spryker locally](/docs/dg/dev/set-up-spryker-locally/set-up-spryker-locally.html). ## Upgrading from B2B and B2C shops to Marketplace To upgrade to marketplace from a regular Demo Shop, follow [How-To: Upgrade Spryker instance to the Marketplace](/docs/dg/dev/upgrade-and-migrate/upgrade-to-marketplace.html). ## Read next [Marketplace concept](/docs/about/all/spryker-marketplace/marketplace-concept.html)

Setting up tests

Mon, 06 Jul 2026 11:41:35 +0000

To get all the things working, you need to prepare a proper organization for your tests. For this, you, first of all, have the root `codeception.yml` file . Its main responsibility is to include other `codeception.yml` files that contain the suite configuration. See [Configuration](/docs/dg/dev/guidelines/testing-guidelines/test-framework.html#configuration) for details. ### Directory structure To organize your tests, follow this structure of the tests directory: ```text tests/ PyzTest/ ApplicationA/ ModuleA/ Communication/ Presentation/ ... codeception.yml ApplicationB ModuleA Communication/ Presentation/ Business/ ... codeception.yml ``` For example, check out the organization within the [tests/PyzTest/](https://github.com/spryker-shop/b2b-demo-marketplace/tree/master/tests/PyzTest) directory. Together with the [root configuration](/docs/dg/dev/guidelines/testing-guidelines/test-framework.html#configuration), you are now able to organize your tests in a way that each test suite can have its own helper applied and can be executed separately. ## Next steps - Learn about the [available test helpers](/docs/dg/dev/guidelines/testing-guidelines/test-helpers/test-helpers.html). - [Create or enable a test helper](/docs/dg/dev/guidelines/testing-guidelines/test-helpers/test-helpers.html).

Set up the Merchant Portal

Mon, 06 Jul 2026 11:41:35 +0000

This document provides details about how to set up the Spryker Merchant Portal. ## Prerequisites To start using Merchant Portal, install Spryker Demo Shop: 1. For the Marketplace project installation, use the [B2B Demo Marketplace repository](https://github.com/spryker-shop/b2b-demo-marketplace). 2. [Install the project](/docs/dg/dev/set-up-spryker-locally/set-up-spryker-locally.html). ## Requirements To build Merchant Portal, install or update the following tools: - [Node.js](https://nodejs.org/en/download/package-manager)—minimum version is v18. - [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm/)—minimum version is v9. ## Overview The main environmental differences between the existing frontends (Yves, Zed) and Merchant Portal are the following: - Minimum Node.js version is v18. - Minimum npm version is v9. Using a *unified* approach, all frontend dependencies must be installed in one step. The entire project is now an *npm workspace*, meaning each submodule declares its dependencies. During the installation stage, npm installs all of those dependencies and stores them into the root of the project. ## Install dependencies and build Merchant Portal ```bash npm install ``` ```bash npm run mp:build ``` All available commands are listed in the `package.json` file in the root folder. Once everything has been installed, you can access the UI of Merchant Portal by going to `$[local_domain]/security-merchant-portal-gui/login`. All Merchant Portal modules are located in the `/vendor/spryker/spryker` directory.

Reporting and handling security issues

Mon, 06 Jul 2026 11:41:35 +0000

Spryker is committed to maintaining a secure platform for all users. This document describes how to report security issues and what to expect during our security issue review and resolution process. ## Reporting a security issue To report a security issue, always send an email to [security@spryker.com](mailto:security@spryker.com). When submitting a report, follow [Vulnerability report submission guidelines](#vulnerability-report-submission-guidelines) to help us understand and process the issue effectively. Our internal security team will get back to you with a confirmation and any follow-up questions if necessary. Do not use public Slack channels or any other public forums to report security issues. ## Vulnerability Disclosure Program Spryker operates a Vulnerability Disclosure Program (VDP) through HackerOne, enabling security researchers to report potential security vulnerabilities responsibly. To participate in the VDP program and submit vulnerability reports via the HackerOne platform, contact us at [security@spryker.com](mailto:security@spryker.com). ## Vulnerability report submission guidelines To help streamline our review process, ensure your submission meets the following criteria: - Submit reports in English - Submit one vulnerability per report, unless multiple vulnerabilities need to be chained to demonstrate impact - Provide a clear description of the vulnerability - Describe detailed steps to reproduce the issue - Provide proof of exploitability such as screenshots or video - Describe the potential impact on users or the organization - Provide a proposed CVSSv3.1 vector and score, excluding environmental and temporal modifiers - List URLs and affected parameters - Include any other vulnerable URLs, additional payloads, and Proof-of-Concept code - Specify the browser, OS, and application version used during testing - Include full URLs and do not use URL shorteners such as tiny URL - Attach all evidence and supporting materials directly in the report; don't user external file hosting services ## How we are handling security reports We process all reports as follows: 1. Confirm the reported issue and notify the reporter. 2. Assess the severity and impact in discussion with the reporter. 3. Develop a fix and coordinate publication: - For Spryker Core (`vendor/spryker*`): - Prepare a project-level code snippet if applicable - Create a code release - Verify the fix with the reporter - Inform customers via the security newsletter - After at least seven working days, publish the fix details in the docs Security releases are not mentioned in product release notes - For Spryker Demo Shops (`b2b-demo-marketplace`, `b2b-demo-shop`, `b2c-demo-shop`): - Prepare a project-level code snippet - Verify the fix with the reporter - Inform customers via the security newsletter - Release the fix in public Demo Shops after seven working days - Publish issue details in the docs after at least seven working days We avoid sending notifications on Friday, Saturday, or Sunday to ensure recipients have at least one working day to act.

PunchOut Gateway

Mon, 06 Jul 2026 11:41:35 +0000

The PunchOut Gateway module provides a basic implementation of OCI and cXML PunchOut flows for Spryker shops. ## Supported use cases The current implementation supports any number of simultaneously active OCI and cXML connections in a single Spryker shop. Support for the shop integration to iFrame can only be enabled globally for the whole shop, following [this guideline](/docs/pbc/all/punchout-gateway/integrate-punchout-gateway.html#support-iframe-embedding). For OCI flow, the cart named `Punchout` is created for every new request. Cart cleanup functionality will be implemented in the following releases. For cXML flow, a single cart is created or reused for each `BuyerCookie` value. ### Additional links [Integration guide](/docs/pbc/all/punchout-gateway/integrate-punchout-gateway.html) explains how to enable cXML and OCI PunchOut flows in your Spryker shop. [Project Configuration](/docs/pbc/all/punchout-gateway/project-configuration-for-punchout-gateway.html) contains details about fine-tuning the integration on the project level.

Product and code releases

Mon, 06 Jul 2026 11:41:35 +0000

To accommodate both the fast pace of innovation and predictability of the upgrade process, we support two types of releases: atomic (code) releases and product releases. ![Product releases flow](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/Release+notes/image2018-8-10_17-10-26.png) ## Atomic (code) releases Atomic, or code release approach, implies that we introduce changes gradually and release updates only for the modified modules. So you don't need to invest time in updating all the modules available in your project every time there is an update. Each Spryker module is released independently and has its own version. Also, every module has its own repository and dependencies declared in a `composer.json` file, which means you can select a specific module version and update it separately. New versions of the existing Spryker modules as well as new modules are integrated into [B2B Demo Marketplace](https://github.com/spryker-shop/b2b-demo-marketplace/) during the product release. The main benefit of the Code Releases is that customers who urgently need new functionality can get access to it by installing corresponding module. We are making sure to provide draft documentation for the new functionality, as well as a module-level migration guide. Our QA team validates the newly released functionality and overall quality of the module but cannot thoroughly check the new module's compatibility with other modules in all required combinations. ## Product releases A product release happens every several months. A product release has its own version and is accompanied by release notes with a respective version. The product release code is stored in our [B2B Demo Marketplace repository](https://github.com/spryker-shop/b2b-demo-marketplace) and includes the most suitable feature set. All of its features are integrated and tested, as well as fully documented. ## Release history See [release-history](https://api.release.spryker.com/release-history) for latest releases including necessary project changes. It also comes with an RSS feed. ## Mailing lists We recommend that you subscribe to our release newsletter and security updates mailing lists so that we can let you know about new features and be immediately informed of any security updates that you need to know about. To join our release notes mailing list, subscribe here:

To receive the security updates, request a subscription at [support@spryker.com](mailto:support@spryker.com). ## Next steps - [Release notes](/docs/about/all/releases/product-and-code-releases.html)

Performance testing in staging environments

Mon, 06 Jul 2026 11:41:35 +0000

Performance testing is an integral part of the development and deployment process. Even if you execute performance testing during development, we highly recommend testing the performance of your code in a staging environment before deploying it in production environments. Since the staging environment isn't designed to be as performant as the production environment, we recommend using a subset of the data and extrapolate the results. If you want to execute a full load test on a production-like dataset and traffic, use a production environment. If you production isn't live yet, you can use directly in that environment. Otherwise, you can order an additional environment by contacting you Account Executive. Testing with real or at least mock data provides significantly better and more reliable results than testing with a small data set. To conduct effective performance tests, we recommend the same data that you're going to use use in the live production environment. If you are unable to use real data for your load tests, you can use the [test data](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/performance-testing-data.zip) for an expanding amount of use cases. Additional support ins't provided for this data. Based on our experience, the [Load testing tool](https://github.com/spryker-sdk/load-testing) can greatly assist you in conducting more effective load tests. ## Load testing tool for Spryker To assist in performance testing, we have a [load testing tool](https://github.com/spryker-sdk/load-testing). The tool contains predefined test scenarios that are specific to Spryker. Test runs based on Gatling.io, an open-source tool. Web UI helps to manage runs and multiple target projects are supported simultaneously. The tool can be used as a package integrated into the Spryker project or as a standalone package. ### Gatling Gatling is a powerful performance testing tool that supports HTTP, WebSocket, Server-Sent-Events, and JMS. Gatling is built on top of Akka that enables thousands of virtual users on a single machine. Akka has a message-driven architecture, and this overrides the JVM limitation of handling many threads. Virtual users are not threads but messages. Gatling is capable of creating an immense amount of traffic from a single node, which helps obtain the most precise information during the load testing. ### Prerequisites - Java 8+ - Node 10.10+ ### Including the load testing tool into an environment The purpose of this guide is to show you how to integrate Spryker's load testing tool into your environment. While the instructions here will focus on setting this up with using one of Spryker's many available demo shops, it can also be implemented into an on-going project. For instructions on setting up a developer environment using one of the available Spryker shops, you can visit our [getting started guide](/docs/dg/dev/development-getting-started-guide.html) which shows you how to set up the Spryker Commerce OS. [B2B Demo Marketplace](/docs/about/all/spryker-marketplace/spryker-marketplace.html) is a starting point for implementations. If you wish to start with a demo shop that has been pre-configured with the Spryker load testing module, you can use the [B2B Demo Marketplace](https://github.com/spryker-shop/b2b-demo-marketplace/). For this example, we will be using the B2B Demo Marketplace. While a demo shop is used in this example, this can be integrated into a pre-existing project. You will just need to integrate Gatling into your project and generate the necessary data from fixtures into your database. To begin, we will need to create a project folder and clone the B2B Demo Marketplace and the Docker SDK: ```bash mkdir spryker-b2b-mp && cd spryker-b2b-mp git clone https://github.com/spryker-shop/b2b-demo-marketplace.git ./ git clone git@github.com:spryker/docker-sdk.git docker ``` #### Integrating Gatling With the B2B Demo Marketplace and Docker SDK cloned, you will need to make a few changes to integrate Gatling into your project. These changes include requiring the load testing tool with composer as well as updating the [Router module](/docs/dg/dev/upgrade-and-migrate/silex-replacement/router/router-yves.html) inside of Yves. {% info_block infoBox %} The required composer package as well as the changes to the Router module are needed on the project level. They are what help to run the appropriate tests and generate the data needed for the load test tool. {% endinfo_block %} 1. Requires the *composer* package. This step is necessary if you are looking to implement the Gatling load testing tool into your project. This line will add the new package to your `composer.json` file. The `--dev` flag will install the requirements needed for development which have a version constraint–for example, "spryker-sdk/load-testing": "^0.1.0"). ```bash composer require spryker-sdk/load-testing --dev ``` 2. Add the Router provider plugin to `src/Pyz/Yves/Router/RouterDependencyProvider.php`. You must import the appropriate class, `LoadTestingRouterProviderPlugin` to initialize the load testing. We also need to build onto the available array, so the `return` clause should be updated to reflect the additions to the array with `$routeProviders`. ```php Depending on your requirements, you can select any combination of the following `up` command attributes. To fetch all the changes from the branch you switch to, we recommend running the command with all of them: > - `--build` - update composer, generate transfer objects, etc. > - `--assets` - build assets > - `--data` - get new demo data You've set up your B2B Demo Marketplace and can now access your applications. #### Data preparation With the integrations done and the environment set up, you will need to create and load the data fixtures. This is done by first generating the necessary fixtures before triggering a *publish* of all events and then running the *queue worker*. As this will be running tests for this data preparation step, this will need to be done in the [testing mode for the Docker SDK](/docs/dg/dev/sdks/the-docker-sdk/running-tests-with-the-docker-sdk.html). These steps assume you are working from a local environment. If you are attempting to implement these changes to a production or staging environment, you will need to take separate steps to generate parity data between the load-testing tool and your cloud-based environment. ##### Steps for using a cloud-hosted environment The Gatling test tool uses pre-seeded data which is used locally for both testing and generating the fixtures in the project's database. If you wish to test a production or a staging environment, there are several factors which need to be addressed. - You may have data you wish to test with directly which the sample dummy data may not cover. - Cloud-hosted applications are not able to be run in test mode. - Cloud-hosted applications are not set up to run `codeception`. - Jenkins jobs in a cloud-hosted application are set up to run differently than those found on a locally hosted environment. - Some cloud-hosted applications may require `BASIC AUTH` authentication or require being connected to a VPN to access. Data used for Gatling's load testing can be found in **/load-test-tool-dir/tests/_data**. Any data that you generate from your cloud-hosted environment will need to be stored here. ###### Setting up for basic authentication If your environment is set for `BASIC AUTH` authentication and requires a user name and password before the site can be loaded, Gatling needs additional configuration. Found within **/load-test-tool-dir/resources/scenarios/spryker/**, two files control the HTTP protocol which is used by each test within the same directory. `GlueProtocol.scala` and `YvesProtocol.scala` each have a value (`httpProtocol`) which needs an additional argument to account for this authentication mode. ```scala val httpProtocol = http .baseUrl(baseUrl) ... .basicAuth("usernamehere","passwordhere") ... .userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0") ``` **usernamehere** and **passwordhere** should match the username and password used for your environment's basic authentication, and not an account created within Spryker. This username and password are typically set up within your deploy file. ###### Generating product data {% info_block errorBox %} You will need to be connected to the appropriate VPN for whichever resource you are trying to access. {% endinfo_block %} Product data can be generated from existing product data for use with the load-testing tool. Within **/load-test-tool-dir/tests/_data**, you will find `product_concrete.csv` which stores the necessary **sku** and **pdp_url** for each product. This information can be parsed directly from the existing data of your cloud-hosted environment. To do so, connect to your store's database. Product data is stored in the `data` column found within the `spy_product_concrete_storage` table as a JSON entry. We can extract this information and format it with the appropriate column names with the following command: ```sql -- `us-docker` refers to your database name. Please make the appropriate adjustments in the SQL query below SELECT JSON_UNQUOTE(JSON_EXTRACT(data, "$.sku")) as `sku`, JSON_UNQUOTE(JSON_EXTRACT(data, "$.url")) as `url` FROM `us-docker`.`spy_product_concrete_storage`; ``` This command parses through the JSON entry and extracts what we need. Once this information has been generated, it should be saved as `product_concrete.csv` and saved in the **/load-test-tool-dir/tests/_data** directory. ###### Generating customer data {% info_block errorBox %} You will need to be connected to the appropriate VPN for whichever resource you are trying to access. {% endinfo_block %} Customer data can be generated from existing product data for use with the load-testing tool. Within **/load-test-tool-dir/tests/_data**, you will find `customer.csv` which stores the necessary fields for each user (email, password, auth_token, first_name, and last_name). Most of this information can be parsed directly from the existing data of your cloud-hosted environment. There are a number of caveats which come with generating this customer data: - To generate information for `auth_token`, a separate Glue call is required. - Passwords are encrypted in the database, while the load-testing tool requires a password to use in plain-text. Because of these aforementioned issues, we recommended creating the test users you need first through the Back Office. For instructions, see [Managing customers](/docs/pbc/all/customer-relationship-management/{{site.version}}/base-shop/manage-in-the-back-office/customers/create-customers.html). Once the users have been created, you will need to generate access tokens for each. This can be done using Glue with the `access-token` end point. You can review the [access-token](/docs/pbc/all/identity-access-management/{{site.version}}/manage-using-glue-api/glue-api-manage-company-user-authentication-tokens.html) documentation for further guidance, but below is a sample of the call to be made. Expected request body ```json { "data": { "type": "string", "attributes": { "username": "string", "password": "string" } } } ``` Sample call with CURL ```bash curl -X POST "http://glue.de.spryker.local/access-tokens" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"data\":{\"type\":\"access-tokens\",\"attributes\":{\"username\":\"emailgoeshere\",\"password\":\"passwordgoeshere\"}}}" ``` {% info_block infoBox %} For each of these, the username is typically the email of the user that was created. Within the response from Glue, you will also want the **accessToken** to be saved for the **auth_token** column. {% endinfo_block %} Once users have been created and access tokens generated, this information should be stored and formatted in `customer.csv` and saved in the **/load-test-tool-dir/tests/_data** directory. Make sure to put the correct information under the appropriate column name. ##### Steps for using a local environment To start, entering testing mode with the following command: ```bash docker/sdk testing ``` Once inside the Docker SDK CLI, to create and load the fixtures, do the following: 1. Generate fixtures and data for the load testing tool to utilize. As we are specifying a different location for the configuration files, we will need to use the `-c` or `--config` flag with our command. These tests will run to generate the data that is needed for load testing purposes. This can be done with the following: ```bash vendor/bin/codecept fixtures -c vendor/spryker-sdk/load-testing ``` 2. As we generated fixtures to be used with the Spryker load testing tool, the data needs to be republished. To do this, we need to trigger all *publish* events to publish Zed resources, such as products and prices, to storage and search functionality. ```bash console publish:trigger-events ``` 3. Run the *queue worker*. The [Queue System](/docs/dg/dev/backend-development/data-manipulation/queue/queue.html) provides a protocol for managing asynchronous processing, meaning that the sender and the receiver do not have access to the same message at the same time. Queue Workers are commands which send the queued task to a background process and provides it with parallel processing. The `-s` or `--stop-when-empty` flag stops worker execution only when the queues are empty. ```bash console queue:worker:start -s ``` You should have the fixtures loaded into the databases and can now exit the CLI to install Gatling into the project. ##### Alternative method to generate local fixtures Jenkins is the default scheduler which ships with Spryker. It is an automation service which helps to automate tasks within Spryker. If you would like an alternative way to generate fixtures for your local environment, Jenkins can be used to schedule the necessary tasks you need for the data preparation step. 1. From the Dashboard, select `New Item`. ![new-item](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/new-item.png) 2. Enter an item name for the new job and select `Freestyle project`. Once you have done that, you can move to the next step with `OK`. ![freestyle-project](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/freestyle-project.png) 3. The next step will allow up to input the commands we need to run. While a description is optional, you can choose to set one here. There are also additional settings, such as a display name, which may also be toggled. As you only need the commands to run once, you can move down to the `Build` section to add the three build steps needed. Click on `Add build step` and select `Execute shell`. A Command field will appear, allowing you to input the following: ```bash APPLICATION_STORE="DE" COMMAND="$PHP_BIN vendor/bin/codecept fixtures -c vendor/spryker-sdk/load-testing" bash /usr/bin/spryker.sh ``` {% info_block errorBox %} Once these fixtures have been generated, attempting to rerun them in the future with the default data files found in **/vendor/spryker-sdk/load-testing/tests/_data/** will cause an error. New data should be considered if you wish to regenerate fixtures for whatever reason. {% endinfo_block %} You can change the store for which you wish to generate fixtures for, that is `AT` or `US`. This command allows Codeception to locate the proper configuration file with the `-c` flag for the load testing tool. Once the fixtures have been generated, the data needs to be republished. We can have Jenkins do that with the same job by adding an additional build step with `Add build step`. ```bash APPLICATION_STORE="DE" COMMAND="$PHP_BIN vendor/bin/console publish:trigger-events" bash /usr/bin/spryker.sh ``` From here, you can either add another build step to toggle the queue worker to run, or you can run the queue worker job already available within Jenkins, that is `DE__queue-worker-start`. ```bash APPLICATION_STORE="DE" COMMAND="$PHP_BIN vendor/bin/console queue:worker:start -s " bash /usr/bin/spryker.sh ``` ![workers](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/workers.png) 4. Once the build steps have been added, you can `Save` to be taken to the project status page for the newly created job. As this is a job that you only need to run once and no schedule was set, you can select the `Build Now` option. ![build-now](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/build-now.png) 5. With the job set to build and run, it will build a new workspace for the tasks and run each build step that you specified. Once the build has successfully completed, you can review the `Console Output` and then remove the project with `Delete Project` once you are finished, if you no longer need it. ![console-output](https://spryker.s3.eu-central-1.amazonaws.com/docs/ca/dev/performance-testing-in-staging-enivronments.md/console-output.png) {% info_block infoBox %} While it's possible to change the Jenkins cronjobs found at **/config/Zed/cronjobs/jenkins.php**, note that these entries require a scheduled time and setting this will cause those jobs to run until they have been disabled in the Jenkins web UI. {% endinfo_block %} You are now done and can move on to [Installing Gatling](#installing-gatling)! #### Installing Gatling {% info_block infoBox %} If you are running this tool, you will need to have access to the appropriate Yves and Glue addresses of your environment. This may require your device be white-listed or may need to be accessed through VPN. Both Java 8+ and Node 10.10+ are requirements to run Gatling from any system. This may also require further configuration on the standalone device. {% endinfo_block %} The last steps to getting the Spryker load testing tool set up with your project is to finally install Gatling. The load testing tool is set up with a PHP interface which makes calls to Gatling to run the tests that have been built into the tool. If you are attempting to load test your production or staging environment and are not testing your site locally, you can skip to the [steps for standalone installation](/docs/ca/dev/performance-testing-in-staging-enivronments.html#installing-gatling-as-a-standalone-package). An installation script is included with the load testing tool and can be run with the following: 1. Enter the tests directory: ```bash cd vendor/spryker-sdk/load-testing ``` 2. Run the installation script: ```bash ./install.sh ``` After this step has been finished, you will be able to run the Web UI and tool to perform load testing for your project on the local level. ##### Installing Gatling as a standalone package It is possible for you to run Gatling as a standalone package. Fixtures and data are still needed to be generated on the project level to determine what loads to send with each test. However, as the Spryker load testing tool utilizes NPM to run a localized server for the Web UI, you can do the following to install it: 1. You will first need to clone to the package directory from the Spryker SDK repository and navigate to it: ```bash git clone git@github.com:spryker-sdk/load-testing.git cd load-testing ``` 2. Once you have navigated to the appropriate folder, you can run the installation script as follows: ```bash ./install.sh ``` This should install Gatling with Spryker's available Web UI, making it ready for load testing. #### Running Gatling To get the Web UI of the Gatling tool, run: ```bash npm run run ``` {% info_block infoBox %} The tool runs on port 3000 by default. If you want to use a different port, specify it in the PORT environment variable. {% endinfo_block %} The tool should now be available at `http://localhost:3000`. The Web UI comes with a variety of pre-built tests. These tests can be run against either the front-end of Yves or through the Glue API. It allows you to set up an instance of a host using the Yves and Glue addresses which can have these tests applied against. Each of the available tests allows you to run with either a growing load or a constant load for a designated amount of time and number of requests per second. Gatling will run the tests specified through the Web UI and then out-put their results in a separate report with charts that can be further broken down. Below is a list of available tests which can be run through the Web UI: For *Yves*: - `Home` - request to the Home page - `Nope` - empty request - `AddToCustomerCart` - scenario to add a random product from fixtures to a user cart - `AddToGuestCart` - scenario to add a random product from fixtures to a guest cart - `CatalogSearch` - search request for a random product from fixtures - `Pdp` - request a random product detail page from fixtures - `PlaceOrder` - request to place an order - `PlaceOrderCustomer` - scenario to place an order For *Glue API*: - `CatalogSearchApi` - search request for a random product from fixtures - `CheckoutApi` - scenario to checkout for logged user - `GuestCheckoutApi` - scenario to checkout for guest user - `CartApi` - scenario to add a product to the cart for logged user - `GuestCartApi` - scenario to add a product to cart for guest user - `PdpApi` - request a random product detail page from fixtures {% info_block errorBox %} Tests like **CartApi** and **GuestCartApi** use an older method of the `cart` end-point and will need to have their scenarios updated. These and other tests may need to be updated to take this into account. Visit the [Glue Cart](/docs/pbc/all/cart-and-checkout/{{site.version}}/marketplace/manage-using-glue-api/carts-of-registered-users/manage-carts-of-registered-users.html#create-a-cart) reference for more details. {% endinfo_block %} ### Using Gatling In the testing tool Web UI, you can do the following: - Create, edit, and delete instances. - Run one of the available tests on a specific instance. - View detailed reports on all the available instances and tests. You can perform all these actions from the main page: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/main-page.png) #### Managing instances You can create new instances and edit or delete the existing ones. ##### Creating an instance To create an instance: 1. In the navigation bar, click **New instance**. The *Instance* page opens. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/instance.png) 2. Enter the instance name. 3. Optional: in the Yves URL field, enter the Yves server URL. 4. Optional: in the Glue URL field, enter the GLUE API server URL. 5. Click **Go**. Now, the new instance should appear in the navigation bar in *INSTANCES* section. ##### Editing an instance For the already available instances, you can edit Yves URL and Glue URL. Instance names cannot be edited. To edit an instance: 1. In the navigation bar, click **New instance**. The *Instance* page opens. 2. Click the *edit* sign next to the instance you want to edit: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/edit-instance.png) 3. Edit the Yves URL or the Glue URL. 4. Click **Go**. Now, the instance data is updated. ##### Deleting an instance To delete an instance: 1. In the navigation bar, click **New instance**. The *Instance* page opens. 2. Click the X sign next to the instance you want to delete: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/delete-instance.png) 3. Click **Go**. Your instance is now deleted. #### Running tests To run a new load test: 1. In the navigation bar, click **New test**. The *Run a test* page opens: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/test.png) 2. Select the instance you want to run the test for. See [Managing instances](#managing-instances) for information on how you can create and manage instances. 3. In the *Test* field, select the test you want to run. 4. In the *Type* field, select one of the test types: - *Ramp*: Test type with the growing load (request per second), identifies a Peak Load capacity. - *Steady*: Test type with the constant load, confirms reliance of a system under the Peak Load. 5. In the *Target RPS* field, set the test RPS (request per second) value. 6. In the *Duration* field, set the test duration. 7. Optional: In the *Description*, provide the test description. 8. Click **Go**. That's it - your test should run now. While it runs, you see a page where logs are generated. Once the time you specified in the Duration field from step 6 elapses, the test stops, and you can view the detailed test report. #### Viewing the test reports On the main page, you can check what tests are currently being run as well as view the detailed log for the completed tests. --- **Info** By default, information on all instances and tests is displayed on the main page. To check details for specific tests or instances, specify them in the *Test* or *Instance* columns, respectively: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/filter.png) --- To check what tests are being run, on the main page, expand the *Running* section. To view the reports of the completed tests, on the main page, in the *Done* section, click **Report log** for the test you need: ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/reports.png) A new tab with the detailed Gatling reports is opened. ### Example test: Measuring the capacity Let's consider the example of measuring the capacity with the `AddToCustomerCart` or `AddToGuestCart` test. During the test, Gatling calls Yves, Yves calls Zed, Zed operates with the database. Data flows through the entire infrastructure. For the *Ramp probe* test type, the following is done: - Ramping *Requests per second* (RPS) from 0 to 100 over 10 minutes. - Measuring the RPS right before the outage. - Measuring the average response time before the outage under maximum load. [56 RPS, 250ms] ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/ramp-probe.png) For the *Steady probe* test type, the following is done: - Keeping the RPS on the expected level for 30 minutes. [56 RPS] - Checking that the response time is in acceptable boundaries. [< 400ms for 90% of requests] ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/steady-probe.png) ### Gatling Reports Gatling reports are a valuable source of information to read the performance data by providing some details about requests and response timing. There are the following report types in Gatling: - Indicators - Statistics - Active users among time - Response time distribution - Response time percentiles over time (OK) - Number of requests per second - Number of responses per second - Response time against Global RPS #### Indicators This chart shows how response times are distributed among the standard ranges. The right panel shows the number of OK/KO requests. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/indicators.png) #### Statistics This table shows some standard statistics such as min, max, average, standard deviation, and percentiles globally and per request. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/statistics.png) #### Active users among time This chart displays the active users during the simulation: total and per scenario. "Active users" is neither "concurrent users" or "users arrival rate". It's a kind of mixed metric that serves for both open and closed workload models, and that represents "users who were active on the system under load at a given second". It's computed as follows: ```text (number of alive users at previous second) + (number of users that were started during this second) - (number of users that were terminated during the previous second) ``` ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/active-users-among-time.png) #### Response time distribution This chart displays the distribution of response times. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/response-time-distribution.png) #### Response time percentiles over time (OK) This chart displays a variety of response time percentiles over time, but only for successful requests. As failed requests can end prematurely or be caused by timeouts, they would have a drastic effect on the computation for percentiles. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/response-time-percentiles-over-time-ok.png) #### Number of requests per second This chart displays the number of requests sent per second overtime. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/number-of-requests-per-second.png) #### Number of responses per second This chart displays the number of responses received per second overtime: total, successes, and failures. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/number-of-responses-per-second.png) #### Response time against Global RPS This chart shows how the response time for the given request is distributed, depending on the overall number of requests at the same time. ![screenshot](https://github.com/spryker-sdk/load-testing/raw/master/docs/images/response-time-against-global-rps.png)

Integrate SCSS linter

Mon, 06 Jul 2026 11:41:35 +0000

Follow the steps below to integrate the [SCSS linter](/docs/dg/dev/sdks/sdk/development-tools/scss-linter.html) into your project. ## 1. Install the dependencies To install the dependencies: 1. Install Stylelint: ```bash npm install stylelint@13.7.x --save-dev ``` 2. Install config for Stylelint: ```bash npm install @spryker/frontend-config.stylelint --save-dev ``` 3. Install the CLI parser: ```bash npm install commander@4.0.x --save-dev ``` ## 2. Update the scripts To update the scripts: 1. Add the SCSS lint script to `/frontend/libs/stylelint.mjs` See this example file: [stylelint.mjs](https://github.com/spryker-shop/b2b-demo-marketplace/blob/master/frontend/libs/stylelint.mjs). 2. Adjust the `/package.json` scripts: ```json "scripts": { .... "yves:stylelint": "node ./frontend/libs/stylelint.mjs", "yves:stylelint:fix": "node ./frontend/libs/stylelint.mjs --fix" } ``` 3. Add the ignore `file /.stylelintignore`: ```text # Ignore paths **/node_modules/** **/DateTimeConfiguratorPageExample/** **/dist/** public/*/assets/** ```