Getting realistic data into a service so it can be developed and demonstrated — initial data, per-tenant content, and believable volumes for testing.
Not covered: It stops at shape, not volume. cds add data fills the right columns with placeholder values; it does not make a name look like a name or an IBAN like an IBAN, and it has no notion of per-tenant fixtures.
Community generators fill db/data with believable values: cap-js-mockdatacap-js-mockdataA cds add command that generates CSV seed files into db/data from @Mockdata annotations on your entities, filling each column with values from the Faker module the annotation names.independent, cap from @Mockdata annotations with Faker, and cap-mock-generatorcap-mock-generatorParses the .cds schema and fills db/data with relationally consistent CSV — through an LLM layer where one is configured, or a local engine where none is.independent, cap from the .cds schema, with relationally consistent rows. @sap/cds-common-content@sap/cds-common-contentISO-standard content for CAP's common definitions — countries, languages, currencies and timezones — so a project does not seed those tables itself.sap official, cap is SAP's ISO content for the common countries, currencies, languages and timezones, and @animb1996/cds-data-drift@animb1996/cds-data-driftCompares the CSV files under a CAP project's db/data with the rows in the database bound as its db service, and reports where the two have diverged without writing to either.independent, cap reports where the CSV files and the deployed rows have diverged.
In ABAP development and test data lives in the system's own tables, so it is entered by hand, kept in eCATT test data containers, or generated by ABAP code that fills them, with localised providers for names and addresses.
eCATT keeps test data apart from test scripts in test data containers, whose parameters describe the data and whose variants hold the values.
Not covered: At values someone entered. A test data container holds what was typed into its variants; believable names and addresses, and the volume a stress test needs, are generated by code written on top.
The repository here is independent; how it relates to eCATT test data containers has not been assessed.
In a UI5 app the service is often a mock server standing in for the OData backend, so the data here is what that mock server answers with: JSON files written by hand or generated from the metadata. Running the mock server itself is UI testingUI5 testingProving a UI still works — unit tests over controllers and formatters, integration tests that drive real controls, and end-to-end runs against a served app.SAP and community, narrow by design.
The OData V2 mock server, sap/ui/core/util/MockServer, answers from JSON files or produces random data from the service metadata it simulates when the files are left out. Apart from the framework, SAP publishes ui5-middleware-fe-mockserver, a UI5 dev server middleware that answers OData V2 and V4 requests of the Fiori elements templates it supports, with a generateMockData option.
Not covered: At values that fit the types. The OpenUI5 documentation says the generated data does not match the business scenario, so believable names and addresses are files someone writes.
No community artifact is documented here.
cds add data arrived, generating seed files with a record count per entity and a CSV or JSON target. Before it, the core loaded CSV but did not produce any. The 7.9 line reached npm on 2024-05-02.
Any guidance that you must hand-write or third-party-generate CSV to get seed data at all. That was true before mid-2024 and is not now — the open question is realism, not volume.
capability:seed-data