diff --git a/driver/cluster.feature b/driver/cluster.feature new file mode 100644 index 00000000..9d3aa4c2 --- /dev/null +++ b/driver/cluster.feature @@ -0,0 +1,63 @@ +# This Source Code Form is subject to the terms of the Mozilla Public +# License, v. 2.0. If a copy of the MPL was not distributed with this +# file, You can obtain one at https://mozilla.org/MPL/2.0/. + +# These tests are dedicated to test the required cluster-specific functionalities of TypeDB drivers. The files in this package +# can be used to test any client application which aims to support all the operations presented in this file for the +# complete user experience. The following steps are suitable and strongly recommended for both CORE and CLOUD drivers. + +# NOTE: It's hard to cover many cluster-specific features in behavior tests, so pay more attention to more flexible +# integration testing. + +#noinspection CucumberUndefinedStep +Feature: Driver Cluster + + Background: Open connection, create driver, create database + Given typedb starts + Given connection is open: false + Given connection opens with default authentication + Given connection is open: true + Given connection has 0 databases + Given connection create database: typedb + Given connection has database: typedb + + ####################### + # ADDRESS TRANSLATION # + ####################### + + Scenario: Driver can work with connection with address translation + Given connection closes + Given connection is open: false + When connection opens with default address translation with default authentication + Then connection is open: true + + Then connection has 1 user + When create user with username 'user', password 'password' + Then connection has 2 users + + Then connection has 1 database + When connection create database: second + Then connection has 2 databases + + When connection open schema transaction for database: typedb + When typeql schema query + """ + define + entity person @abstract, owns name; + attribute name, value string; + """ + Then transaction commits + Then connection get database(typedb) has schema: + """ + define + entity person @abstract, owns name; + attribute name, value string; + """ + + When connection open read transaction for database: typedb + When get answers of typeql read query + """ + match entity $p; + """ + Then answer size is: 1 + diff --git a/driver/connection.feature b/driver/connection.feature index e45c5458..22328ae2 100644 --- a/driver/connection.feature +++ b/driver/connection.feature @@ -59,6 +59,29 @@ Feature: Driver Connection Then connection is open: true Then connection has database: typedb + + Scenario: Driver can retrieve server version information + Then connection contains distribution + Then connection contains version + When connection closes + When connection opens with default authentication + Then connection contains distribution + Then connection contains version + + ########### + # REPLICA # + ########### + # Cluster-specific, but the API should not lead to crashes even without clustering, and we test it here + + @ignore-typedb-http + Scenario: Driver can retrieve server replica list + Then connection has 1 replica + + + @ignore-typedb-http + Scenario: Driver can retrieve primary server replica + Then connection contains primary replica + ############# # DATABASES # ############# diff --git a/driver/http/http.feature b/driver/http/http.feature index ed3fb851..eec02f89 100644 --- a/driver/http/http.feature +++ b/driver/http/http.feature @@ -25,6 +25,7 @@ Feature: TypeDB HTTP Endpoint Then connection is healthy: true + # TODO: Remove this as we check it in connection now! Cleanup the steps from the server. Scenario: Version and distribution are returned from version Then get endpoint(/v1/version) contains field: distribution Then get endpoint(/v1/version) contains field: version diff --git a/driver/user.feature b/driver/user.feature index 7b83373e..f1a5f610 100644 --- a/driver/user.feature +++ b/driver/user.feature @@ -170,9 +170,9 @@ Feature: Driver User Given connection opens with username 'admin', password 'password' When create user with username 'user', password 'password' When delete user: user - Then delete user: user; fails with a message containing: "User does not exist" - Then delete user: user2; fails with a message containing: "User does not exist" - Then delete user: surely-non-existing-user; fails with a message containing: "User does not exist" + Then delete user: user; fails with a message containing: "User not found" + Then delete user: user2; fails with a message containing: "User not found" + Then delete user: surely-non-existing-user; fails with a message containing: "User not found" # TODO: Not sure if it's correct, may be implemented differently Scenario: User's name is retrievable only by admin