Skip to content

Releases: gdt-dev/gdt

v1.5.0

01 Jun 13:16
d9a4f14
Compare
Choose a tag to compare

What's Changed

Breaking developer SDK change

This is a breaking change for GDT plugin developers, not GDT users

  • rework debug/print into a tracing context by @jaypipes in #21

Full Changelog: v1.4.0...v1.5.0

v1.4.0

27 May 12:48
de1ef61
Compare
Choose a tag to compare

What's Changed

Breaking developer SDK change

This is a breaking change for GDT plugin developers, not GDT users

  • add context.Context arg to assertions.OK() by @jaypipes in #20

Full Changelog: v1.3.0...v1.4.0

v1.3.0

15 Jan 15:21
1a7e229
Compare
Choose a tag to compare

New features

  • Ability to specify none and in for exec plugin's err and out fields (#16)
  • Ensure all parse-time errors include line number and column where error was found (#14)

Breaking changes (developer SDK, not gdt test file format)

  • The Assertion.Terminal() method has been removed since it was no longer used anywhere (#17)

v1.2.1

14 Aug 19:46
1360915
Compare
Choose a tag to compare

Adds more descriptive parse-time errors.

v1.2.0

09 Aug 20:53
13c1ecd
Compare
Choose a tag to compare

Support for on.fail field in exec plugin tests (#13)

Users would like to be able to execute commands, collect log
information, grep for errors in output and other actions when a test
assertion fails.

For instance, if an application is deployed using Kubernetes and network
connectivity doesn't work for the application, the test author might
want to call kubectl logs in the event of a test failure.

Another example might be if you wanted to grep a log file in the event
that no connectivity on a particular IP:PORT combination could be made
you might do this:

tests:
 - exec: nc -z $HOST $PORT
   on:
     fail:
       exec: grep ERROR /var/log/myapp.log

The grep ERROR /var/log/myapp.log command will only be executed if there
is no connectivity to $HOST:$PORT and the results of that grep will be
directed to the test's output. You can use the gdt.WithDebug() function
to configure additional io.Writers to direct this output to.

v1.1.1

08 Aug 14:29
0d8a00e
Compare
Choose a tag to compare

Fixes for #7 and #8

Don't add non-Scenario files to Suite and ensure t.Error() is called from sub-test, not scenario

v1.1.0

30 Jul 13:17
d75461c
Compare
Choose a tag to compare

New functionality

Skip scenario if condition true (#5)

Adds the ability to skip a test scenario if a condition evaluates to true. Use the skip-if field in the Scenario YAML to tell gdt to skip the scenario if that condition evaluates to true. The condition is just a test.

For example, let's assume you have a gdt-kube scenario that looks like
this:

tests:
 - kube.create: manifests/nginx-deployment.yaml
 - kube:
   get: deployments/nginx
   assert:
     matches:
       status:
         readyReplicas: 2
 - kube.delete: deployments/nginx

If you execute the above test and there is already an 'nginx'
deployment, the kube.create test will fail. To prevent the scenario
from proceeding with the tests if an 'nginx' deployment already exists,
you could add the following

skip-if:
 - kube.get: deployments/nginx
tests:
 - kube.create: manifests/nginx-deployment.yaml
 - kube:
   get: deployments/nginx
   assert:
     matches:
       status:
         readyReplicas: 2
 - kube.delete: deployments/nginx

With the above, if an 'nginx' deployment exists already, the scenario
will skip all the tests.

Breaking changes in YAML definitions

exec plugin assertions now under assert field (#6)

The exec plugin now nests its assertions under an assert field.

So, instead of this:

tests:
 - exec: echo cat
   out:
     is: cat

you now do this:

tests:
 - exec: echo cat
   assert:
     out:
       is: cat

require renamed to fixtures (#2)

The require field in the Scenario YAML definition has been renamed to the more appropriate fixtures, since this field lists the fixtures that the scenario requires.

v1.0.1

25 Jul 23:07
Compare
Choose a tag to compare

Code identical to v1.0.0. Cleaned up some links in README and needed to cut a new release after mis-tagging v1.0.0 as v.1.0.0

v1.0.0

25 Jul 22:52
Compare
Choose a tag to compare

Initial port of github.com/jaypipes/gdt-core and github.com/jaypipes/gdt merged into a single package.

To use gdt, define your tests in a YAML file or a directory containing YAML files, use the gdt.From() method to create a runnable test suite or scenario and then Run() it:

package mypackage_test

import (
	"context"
	"path/filepath"
	"testing"

	"github.com/gdt-dev/gdt"
	"github.com/stretchr/testify/require"
)

func TestRunASuite(t *testing.T) {
	require := assert.New(t)

	fp := filepath.Join("suite", "testdata", "exec")
	s, err := gdt.From(fp)
	require.Nil(err)
	
	s.Run(context.TODO(), t)
}

func TestRunOneScenario(t *testing.T) {
	require := require.New(t)

	fp := filepath.Join("suite", "testdata", "exec", "ls.yaml")
	s, err := gdt.From(fp)
	require.Nil(err)

	s.Run(context.TODO(), t)
}