Skip to content

owncloud/cs3api-validator

Repository files navigation

cs3api-validator

Build Status Open Source Love License Rocket chat

End-to-End Test Suite for the CS3 APIs

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.

Purpose

BDD (Behavior driven development)

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.

Litmus Testing

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.

Contributions

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.

Getting help

We have a Public Chat where you can chat with other community members and developers.

Here are some useful channels to try:

  • #ocis - Next Generation ownCloud Architecture
  • #general - General Topics around File Sync & Share

Developing

Quick start

git clone [email protected]:owncloud/cs3api-validator.git
cd cs3api-validator
go test -v # default network addr of cs3api provider is localhost:9142

Add features

Add 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 remaining

Then 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)
}

Usage

Run with go test

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.

In a working go environment

Run go test --endpoint=your-addr:port -v

Build a binary with the tests

Run go test -c. This will create a cs3api-validator.test binary.

Execute the tests ./cs3qpi-validator.test --endpoint=your-addr:port

Use tags

You can use tags to filter features which should be executed. --godog.tags=<expression>

License

Apache-2.0