SAP Spartacus Definition of Done


SAP Spartacus Definition of Done)

Coding guidelines

The Spartacus team adopted the following set of rules to maintain the readability and maintainability of Spartacus code. As a contributor, we ask you to follow these rules (even if you find them violated somewhere). When files always don’t follow these rules and following them will make the code worse, follow the local style.


You can run build. Exe, which is located at the root of the project SH script. It will run most of the checks or rules mentioned below, such as linting and prettier checks, running unit tests, end-to-end tests, and so on.



We use TSLint to analyze and improve our typescript code.

You can run the following command to lint your code:

yarn lint

We also encourage you to use the TSLint plugin in VS Code.

Coding Format

We use prettier to format our code (and make it more beautiful).

To check that all files are beautified, run the following command:

yarn prettier

To format and beautify your code base, run the following command:

yarn prettier:fix

We also encourage the use of the prettier vs code plug-in. For more information, see Spartacus development tools.

SCSS is Preprocessed (node-sass)

We use Sass for all of our CSS, which then is converted to CSS using node-sass.

Use the following command to preprocess the Sass in projects/storefrontstyles

yarn sass

unit testing

Spartacus code requires unit testing. Ensure that new features or errors have unit tests and that they pass.

Run the following command to run the unit test of the Library:

yarn test [project]

yarn test storefrontlib

When you run the test, chrome will open and you can see the progress and details of the test, including whether the test has passed.

Unit test code coverage

Please ensure that unit test coverage is >= 80% for everything, and >=60% for branches.

To get the test coverage report, run the following commands:

yarn test [project] –code-coverage

yarn test storefrontlib –code-coverage

Alternatively, you can run the following commands:

yarn test [project] –code-coverage

yarn test:core:lib

The coverage report can be found in ./coverage/index.html.

End to end testing

All new features in Spartacus require end-to-end testing written using cypress. Make sure that the new features have end-to-end testing and that they are passing.

Where applicable, write end-to-end tests to ensure that your new or updated features are safe. If writing end-to-end tests makes sense, the minimum requirement is to write basic UI end-to-end tests. You can also consider writing UI end-to-end tests using user flow, but this is optional.

All newly written end-to-end tests must be reviewed, updated, or reused. They should also follow the end-to-end testing guidelines.

Run the following command to perform an end-to-end test:

  • yarn e2e:cy:run # smoke tests
  • yarn e2e:cy:run:mobile # mobile tests
  • yarn e2e:cy:run:regression # regression tests

Note: before running the end-to-end test, ensure that the dependencies are installed in projects / storefrontapp-e2e-cypress and that the application is running.

The goal of end-to-end testing is to ensure that your functionality works properly. For example, if you want to implement a simple login screen with two buttons, such as login and Cancel buttons, you can write the following tests:

  • Log in with valid credentials
  • Attempt to login with invalid credentials
  • Fill in the input fields and click the Cancel button.

Note: E2E test can only be run in SAP at present. We are working to make E2E testing public to contributors.

Browser compatibility

In order for the new function to meet the completed definition, at least the manual and happy path test of the new function must be successful, and there are no obvious layout problems in the latest major versions of the following browsers:

  • Chrome
  • Firefox
  • Safari
  • Edge

The Library Builds Without Errors

Run the following command to ensure the libraries build without errors:

yarn build:libs

There are no errors when shell starts

Run the following command to ensure that the shell storefront application starts without errors:

yarn start

After running the command, you should see the following:

  • There is no error in the webpack terminal output
  • When displaying the home page, the JS console in Chrome has no errors.

Happy path, a new feature in shell app

Run the smoke test of this function and deploy it in the library of shell application.

Then determine whether the new feature needs to be changed in the shell application or configuration file.

Some files and concepts exist in the shell application itself. Ask yourself if the new code needs to update your shell application or configuration file.

The following changes may be candidates:

  • Add or change route
  • Add or change modules (change path or name)
  • add component
  • add module
  • Change how the configuration mechanism works.

Verify production build work

Run the following command to verify that the production build is valid, especially the advance (AOT) compiler:

yarn build:libs

yarn start

Here are some reasons why production builds can fail:

  • Due to AOT, we must explicitly specify some types, such as function return type. Although typescript does not need them, it can infer them.

Use index Be careful when using TS files (i.e. bucket files). When running a production build, you may see the following errors in the node / webpack console:

ERROR in : Encountered undefined provider! Usually this means you have a circular dependencies (might be caused by using ‘barrel’ index.ts files.

This is usually caused by import statements, such as:

import * as fromServices from ‘../../services’。

Instead, you should import each class specifically, as shown in the following example:

import { OccCmsService } from "../../services/occ-cms.service";

import { DefaultPageService } from "../../services/default-page.service";