Note: curretly this test verifies standalone KillBill module deployed on Kubernetes cluster. Test is based on the assumption that we collect and measure usage of gigabyteseconds consumed by customer's instances and we calculate account balance per billing period based on fixed price per each gigabytesecond.
For now, all the functions in this simple billing cycle are simulated by the test suite by sending REST API calls to the KillBill API. In the next step, these simulated behaviours should be replaced by actual integrations with the Scramjet Cloud Platform backend and GUI.
KillBill - Subscription Billing
For KillBill deployment on k8s, please check this k8s-charts directory
Test uses env-cmd node package. You can pass environment variables from this .env or set them on command line while running billing test, for example ADMIN_USERNAME=superadmin yarn test:bdd --name="BILL-001"
Example .env file is provided as .env.sample file
# Based on this file you can create your own .env file placed in the root directory of this project
# Endpoint of the KillBill REST API Service
BILLING_ENDPOINT=http://<IP address/URL>:<Port>
# API Key set for the KillBill tenant
API_KEY=<Value from KillBill Tenant settings>
# API Secret set for the KillBill tenant
API_SECRET=<Value from KillBill Tenant settings>
# Admin username set for the KillBill tenant
ADMIN_USERNAME=<Value from KillBill Tenant>
# Admin password set for the KillBill tenant
ADMIN_PASSWORD=<Value from KillBill Tenant>In order to run this test, you need to execute the foloing steps:
- Clone this repository
- Ensure you have KillBill:
- deployed on k8s (either locally or on Scramjet remote cluster)
- that it has configured tenant with API key and API secret
- that you can access its REST API endpoint from test machine
- Ensure you have access credentials to KillBill:
- Priviledged user credentials (user that can execute API request, such as tenant admin) - username and password
- Tenat's API key and API secret
- Configure environment variables in .env file (check .env.sample for help) or set them them during calling
yarn test:bdd(for exampleADMIN_USERNAME=admin yarn test:bdd --name="BILL-001"]) - Build the project
yarn clean && yarn install && yarn build:all - Run the project
yarn test:bdd --name="BILL-001" - Check the
./bdd/reportsfor report result
Test is using simplified KillBill catalog configuration represented by config/catalog.xml file. This is purely test configuration, not intended to be used directly on production. It defines:
- simple BASIC_PLAN with daily billing period
- usage unit named
gigabytesecond - fixed USD price for one
gigabytesecond
This simple catalog file is uploaded to KillBill tenant for every test case. In case such catalog exists already, it is overwritten with the same file. This way, no additional manual configuration is requied for the test.
In case of changes required in the catalog, one can validate config/catalog.xml file with config/catalog.xsd file provided by KillBill.
Test project currently executes two scenarios:
- BILL-001 TC-001 Billing test gigabyteseconds simple usage
Given billing module is available
When product catalog is uploaded to the billing tenant
When new customer account for company "ACME" is registered
Then customer account Id is retrieved by external key
When SCP subscription is created for customer account
Then subscription Id is retrieved by external key
When instances gigabyteseconds usage is registered
Then trigger dry run invoice generation and check balance amount
Then trigger actual invoice generation
- BILL-001 TC-002 Billing test gigabyteseconds usage with credit from voucher
Given billing module is available
When product catalog is uploaded to the billing tenant
Then new customer account for company "COMPANY2" is registered
Then customer account Id is retrieved by external key
When SCP subscription is created for customer account
Then subscription Id is retrieved by external key
When voucher "VX32423" credit amount 100.00 is added to the customer account
When instances gigabyteseconds usage is registered
Then trigger dry run invoice generation and check balance amount
Then trigger actual invoice generation
Example test result can be found below:
