Test structure

Physical test location

Tests located in database schemes / packages or procedures

Yests organized in project into folders/spec files

Physical test organization

Strict - database oriented
Schema/package/procedure

Flexible - project oriented
Within a test file, tests organized into nestable example groups

Logical test organization

Limited to package level grouping
Packages can be organized into suites
Each suite can contain many packages
Each package can be placed in many suites

Flexible
Each test(example) can be labelled with tags
Each example group can be labelled with tags
Each tag can be assigned to many tests/example groups

Test execution granularity

All tests in a single test package
or All tests in a single suite of test packages

Single test
or All tests in a specified example group
or All tests in a mask-specified directory/file
or All test with a specific tag(s)
or All tests except specific tag(s)
and more

Identifying and naming tests

Each assertion has a mandatory text description
Assertion is a test

Each example group can have a descriptive free text name
Each example can have a descriptive free text name
Each example can contain many assertions composing the test

Re-usable tests/shared examples

NO
Separate tests are needed for two functions do the same thing but on different objects(datatypes)

YES
Standard of shared examples for testing of identical behavior on different objects(datatypes)

Test suites definition

Defined in database tables

Defined as tags in test definition files or by test file location in directory structure

Suites management

Calls to API prior to test execution, persisted in DB per user

Tags defined beside the test definition in test files

Reporting configuration

Calls to API prior to test execution, persisted in DB per user

Parameter when executin tests

Customizations within test/suite/project

NO
One common library per database

YES
Own assertions/configurations can be added to tests or project