Changes

1. Few changes in service DebuggerService from debugger subpackage.
2. Support for HTML

• ability to detect HTML format
• ability to query HTML nodes to assert against in appropriate methods

3. Research

• see whether antchfx/jsonquery may be used as PathFinder implementation in pathfinder subpackage
• see whether qri-io/jsonschema may be used as json schema validator implementation into schema subpackage.

TODO:

• Make changes in DebuggerService from debugger subpackage
• Add support for HTML
• Do research for new PathFinder and Validator

PS: all changes should be merged to v1.2.0 branch created for this issue

Background

pkg/pathfinder is package that contains various services that allow to query structured data

Objective

• Remove QJSONFinder service and its corresponding method from package as it is not used anymore

Background

PathFinder describes ability to obtain node(s) from data in fixed data format. Project supports few data formats and therefore ships few PathFinder implementations that are able to work with those data formats.

SchemaValidator describes entity that can validate document against some kind of schema. At this moment there is only one implementation available that allows to validate document against JSON schema.

Objective

• Make research whether antchfx/jsonquery may be used as new implementation of PathFinder and whether it would be beneficial to do so (check if its better than current implementations available in project). If so - write this implementation
• Make research whether qri-io/jsonschema may be used as implementation of SchemaValidator and whether it would be beneficial to do so. If so - write this implementation.

Explore new candidate for another JSON Formatter and/or PathFinder: https://github.com/tidwall/gjson

I just stumbled across this repo and it is brilliant. Have you ever explored using the client generated code from https://github.com/go-swagger/go-swagger to wrap around godog tests so that we can leverage all the request objects? Or is that something we could collaborate on here?

1. Explore new candidate for another JSON Formatter and/or PathFinder: https://github.com/tidwall/gjson

2. Following methods:

• AssertNodeIsType
• AssertNodeIsNotType
• AssertNodeIsTypeAndValue

accepts "nil", "string", "int", "float", "bool", "map", "slice" as type argument.

Methods should be able to detect data types related with JSON / YAML.

So, methods should now accept also following types:

• JSON: null, array, object, number, boolean
• YAML: scalar, list, dictionary

Currently accepted types should remain available for any data format.

Internal methods implementation should change. Required changes are:

• Add new services container to APIContext: TypeCheckers
• TypeCheckers container should contain fields: JSON, YAML, which holds services for corresponding formats.

Add new subpackage: typecheck with TypeChecker interface definition and implementation for JSON and YAML formats.

3. Add new methods:

• AssertResponseCookieValueMatchesRegExp
• AsserNodeContainsSubString
• AssertNodeNotContainsSubString
• AssertNodeIsTypeAndHasOneOfValues

4. Add examples to tests wherever possible

TODO:

• #25
• #26
• #27
• #28

Add following methods:

• method for preserving last HTTP response header
• negation of current method: TheResponseShouldHaveHeader (the response should not have
• negation of current method: TheResponseShouldHaveCookie
• negation of current method: TheResponseShouldHaveNode
• negation of current method: TheResponseStatusCodeShouldBe
• negation of current method: TheResponseBodyShouldHaveFormat
• negation of current method: TheNodeShouldBeSliceOfLength
• negation of current method: TheNodeShouldMatchRegExp

Following methods:

AssertNodeIsType
AssertNodeIsNotType
AssertNodeIsTypeAndValue

accepts "nil", "string", "int", "float", "bool", "map", "slice" as type argument.

Methods should be able to detect data types related with JSON / YAML.

So, methods should now accept also following types:

JSON: null, array, object, number, boolean
YAML: scalar, list, dictionary

Currently accepted types should remain available for any data format.

Internal methods implementation should change. Required changes are:

Add new services container to APIContext: TypeMappers
TypeMappers container should contain fields: JSON, YAML, Go which holds services for corresponding formats.

Add new subpackage: types with Mapper interface definition and implementation for JSON, YAML and Go-like formats.

Background

gdutils is library with useful method for testing HTTP(s) API.

Objective

Create new method that allows to randomly pick one of predefined values.

For example, cucumber wrapper of such method may look like this

Given I pick randomly one "(string|int|float64)" of "value1|value2|value3"

Creator of such method should pre-define separator used for different values passed in last argument (example uses |)

Add new methods:

• AssertResponseCookieValueMatchesRegExp: similar to this method, but allows to pass reg exp instead of exact value.
• AsserNodeContainsSubString: similar to this but assumes response node value is of type: string and allows to pass only substring to check against.
• AssertNodeNotContainsSubString - similar to above, but negation
• AssertNodeIsTypeAndHasOneOfValues - similar to this, but checks against one of provided values instead of one.

Methods: IGenerateARandomRunesInTheRangeToAndSaveItAs and IGenerateARandomSentenceInTheRangeFromToWordsAndSaveItAs not only should change name as described above, but they should emphasize that they do not produce final output, but generator funcs instead.

Background

Project supports various formats like JSON, YAML, XML and plain text.

Objective

Format package contains functions that helps detect whether given slice of bytes contains data in given format. Currently, there is missing function IsPlainText.

Task is to write that kind of function. Implementation is up to developer. Function should have unit tests.
Weakest assumption may be that any non 0 length slice of bytes is detected as plain text. More sophisticated logic may use other package functions like IsJSON or IsXML to check whether those slice of bytes is detected as JSON or XML for example. If so, it assumes it is not plain-text.

Note, that it is not easy to guarantee any format so don't bother if function is not 100% correct.

• implement IsPlainText function
• update code here and here and use previously created method IsPlainText

1. APIContext struct methods follow "godog" convention for naming. This is subject to change.

For example:

IPrepareNewRequestToAndSaveItAs may be changed to RequestPrepare,
ISetFollowingHeadersForPreparedRequest may be changed to RequestSetHeaders,
TheResponseShouldHaveNodes may be changed to AssertNodesExist.

2. Methods: IGenerateARandomRunesInTheRangeToAndSaveItAs and IGenerateARandomSentenceInTheRangeFromToWordsAndSaveItAs not only should change name as described above, but also change from and to arguments to float64. In another words it should generate random float, from provided float interval.

3. Method IGenerateARandomFloatInTheRangeToAndSaveItAs should not only change name, but also be modified so it returns generator func. This func should accept argument that sets rounding for output (for example, to 2 digits after dot) and return generating func that accepts left and right end of interval as float64 instead int like currently.

4. Upgrade minimal golang version to 1.18 and replace all occurences of interface{} with any

5. Add following methods:

• method for preserving last HTTP response header value
• negation of current method: TheResponseShouldHaveHeader (the response should not have header)
• negation of current method: TheResponseShouldHaveCookie
• negation of current method: TheResponseShouldHaveNode
• negation of current method: TheResponseStatusCodeShouldBe
• negation of current method: TheResponseBodyShouldHaveFormat
• negation of current method: TheNodeShouldBeSliceOfLength
• negation of current method: TheNodeShouldMatchRegExp

AC:

• #13
• #16
• #14
• #15
• #12
• Update README.MD, doc.go and unit tests according to changes

Background

debugger represents utility service responsible for debugging whole testing process. Its implementation DebuggerService is used in default ApiContext constructor. Its main method is Print(info string) which basically prints whatever is passed as info to stdout with little modification.

Objective

Make few enchancements to DebuggerService as follows:

• Service should have ability to truncate output from Print method to fixed number of bytes. This particular setting should be passed in service constructor (method New). For example, if data passed to Print(info string) method exceeds 1024 bytes, output should be truncated to 1024 bytes with additional info, that output was truncated.
• if info argument passed to Print method is detected as JSON string, then output should be indented for better readability.
• research whether Print method may color output if it detects info argument as JSON string. To do it - use this package.

Background

Project supports various formats like JSON, YAML, XML and plain text.

Objective

Format package contains functions that helps detect whether given slice of bytes contains data in given format. Currently, function that detects XML doesn't work good enough.

Task is to change IsXML function to make it work better. Additional unit tests should be added also.

New logic may check whether slice of bytes contains substring similar to <?xml version="1.0". It is up to developer to create this logic.

Note, that it is not easy to guarantee any format so don't bother if function is not 100% correct.

• fix IsXML function

Background

pkg/formatter is utility package that defines services that knows how to serialize/deserialize data into different data formats.

Objective

• rename package to serializer
• remove AwareFormatter as it is not used anymore
• Rename services (structs) with following pattern: JSONFormatter -> JSON, the same for rest

Background

Package contains 3rd party packages defined in go.mod.

Objective

Each of those packages may be updated and task is to examine each of them and see if we can use newer version and eventually update it in go.mod

Task objective is to check all possible methods and try to create at least one example for each.

Background

pkg/debugger is utility package that defines simple service useful for debugging purposes.

Objective

Current debugger works, yet is not perfect. Task is to re-design this service to make it more useful and convenient to use. Things to consider:

• how to display logs in more appealing way (maybe as JSON)
• should it display: currently run scenario name, affected method name, tip for user how to solve issue
• should output be limited by default to N-number of bytes (and if, should it be displayed that output is truncated ?)
• naming for service and intuitive methods names

Is blocked by #48

Background

pkg/cache is utility package that defines services which allows to persist data in memory having convenient to use facade.

Objective

• Remove DefaultCache as it is not used and not safe to use by multiple goroutines.
• Rename ConcurrentCache to Concurrent
• Add short description of each method

Method IGenerateARandomFloatInTheRangeToAndSaveItAs should not only change name, but also be modified so it returns generator func. This func should accept argument that sets rounding for output (for example, to 2 digits after dot) and return generating func that accepts left and right end of interval as float64 instead int like currently.

EDIT: Due to this discovery, please do not create generator func. Just create func with signature similar to:

// GenerateFloat64 generates pseudo-random float64 from provided interval and save it in cache under provided cacheKey
func (apiCtx *APIContext) GenerateFloat64(from, to float64, cacheKey string) error

Background

pkg/mathutils defines mathematics related functions. Current functions RandomInt and RandomFloat64 returns not only int and float64 correspondingly, but also error. This error happens when from argument is greather than to argument. Although it is correct, it is also polluting code with unecessary ifs.

Objective

Having new functions MustRandomInt and MustRandomFloat64 which do not return error would be convenient in cases when arguments passed to those functions are fixed and not passed from variable.

• Add new function MustRandomInt which is similar to already defined RandomInt, but returns only int and panics if from argument is greater than to argument
• Add new function MustRandomFloat64 which is similar to already defined RandomFloat64, but returns only float64 and panics if from argument is greater than to argument
• since go1.20 rand.Seed is depreciated. Please see why and adjust code to it

APIContext struct methods follow "godog" convention for naming. This is subject to change.

For example:

IPrepareNewRequestToAndSaveItAs may be changed to RequestPrepare,
ISetFollowingHeadersForPreparedRequest may be changed to RequestSetHeaders,
TheResponseShouldHaveNodes may be changed to AssertNodesExist.

Background

Currently project allows to work with few data formats. To make it happen there are methods and structs related with particular format across whole project that allows to work with them. Good start to find them is to look here. Those are PathFinders, TypeMappers and more.. Those utility structs and methods are used in APIContext's methods and can be found in steps.go file.

Objective

• Look over project and find necessary utilities to enchance/upgrade/add to work with HTML (look in JSON, YAML or XML analogies).
• Research whether antchfx/htmlquery can be used as PathFinder implementation for HTML tree.

Background

Some of packages defined under pkg/ for example pkg/cache contains exported interfaces which are used by root module/package. See APIContext definition as example of that kind of usage.

Objective

Following best practices those interfaces should be removed from source package and defined in client package. Newly defined interfaces should not be exported.

For example cache.Cache should be removed from pkg/cache and re-defined in root level (interfaces.go)

• create interfaces.go file in root of package
• query all subpackages of pkg/ and remove exported interfaces from each subpackage
• re-define those interfaces as local not exported interfaces of root package of library

go mod should accept minimal version of go: 1.18. Package and all sub packages should update their interface{}s to any