This tool will receive a lot of changes before version 1.0.0
The cs3api-validator is a tool to test implementations of the CS3Apis. It works as standalone software which only needs the address of a running cs3api provider.
The cs3api-validator can be run locally in a development phase to develop against a well-defined set of basic API operations. It has no external dependencies and runs human-readable gherkin test scenarios. This helps to understand the behavior of the CS3APIs being an additional way of documenting the API in combination with the specification.
This tool makes it possible to confirm that an implementation of the CS3APIs is compliant to the spec and fulfills the basic operations. This helps the CS3 community to keep different implementations in sync and foster compatibility between them.
This is a community driven Open Source Project. We welcome contributions from everyone and we're ready to support you if you have the enthusiasm to contribute.
Please use the issue tracker to report problems or propose changes.
We have a Public Chat where you can chat with other community members and developers.
Here are some useful channels to try:
git clone [email protected]:owncloud/cs3api-validator.git
cd cs3api-validator
go test -v # default network addr of cs3api provider is localhost:9142Add new test steps to the feature files in the features directory.
Feature: eat godogs
In order to be happy
As a hungry gopher
I need to be able to eat godogs
Scenario: Eat 5 out of 12
Given there are 12 godogs
When I eat 5
Then there should be 7 remainingThen run go run github.com/cucumber/godog/cmd/godog@master which will output something similar like this
Feature: eat godogs
In order to be happy
As a hungry gopher
I need to be able to eat godogs
Scenario: Eat 5 out of 12 # features/godogs.feature:6
Given there are 12 godogs
When I eat 5
Then there should be 7 remaining
1 scenarios (1 undefined)
3 steps (3 undefined)
220.129µs
You can implement step definitions for undefined steps with these snippets:
func iEat(arg1 int) error {
return godog.ErrPending
}
func thereAreGodogs(arg1 int) error {
return godog.ErrPending
}
func thereShouldBeRemaining(arg1 int) error {
return godog.ErrPending
}
func InitializeScenario(ctx *godog.ScenarioContext) {
ctx.Step(`^I eat (\d+)$`, iEat)
ctx.Step(`^there are (\d+) godogs$`, thereAreGodogs)
ctx.Step(`^there should be (\d+) remaining$`, thereShouldBeRemaining)
}
Then copy the new step definition stubs to a *_test.go file and implement the steps. In this project we use a FeatureContext struct to share values between the tests steps. In order to do this we need to use a pointer to the FeatureContext as a function receiver in the test step methods.
func (f *FeatureContext) iEat(arg1 int) error {
return godog.ErrPending
}
func (f *FeatureContext) thereAreGodogs(arg1 int) error {
return godog.ErrPending
}
func (f *FeatureContext) thereShouldBeRemaining(arg1 int) error {
return godog.ErrPending
}
func InitializeScenario(ctx *godog.ScenarioContext) {
f := &FeatureContext{}
ctx.Step(`^I eat (\d+)$`, f.iEat)
ctx.Step(`^there are (\d+) godogs$`, f.thereAreGodogs)
ctx.Step(`^there should be (\d+) remaining$`, f.thereShouldBeRemaining)
}You can run the tests with the built-in go test command. The command passes its flags to the godog test suite. The test suite needs one flag to be set: The network address of the running system under test. It defaults to localhost:9142 and you can set it using the --endpointflag.
NOTE: If you want to use the godog flags you need to prefix them with
godog.flagname.
Run go test --endpoint=your-addr:port -v
Run go test -c. This will create a cs3api-validator.test binary.
Execute the tests ./cs3qpi-validator.test --endpoint=your-addr:port
You can use tags to filter features which should be executed. --godog.tags=<expression>
Apache-2.0