func (t *TestCase) ApplyInput(rulectx *Context) (*resty.Request, error) {
	if t.Input.Method == "" {
		return nil, t.AppErr("error: TestCase input cannot have empty input.Method")
	}
	req, err := t.Input.CreateRequest(t, rulectx)
	if err != nil {
		return nil, t.AppErr("createRequest: " + err.Error())
	}

	t.Request = req // store the request in the testcase
	return req, err
}
// ApplyInput - creates an HTTP request for this test case
// The reason why we're doing this is that a testcase behaves like an http object
// It produces an http.Request - which can be sent to a server
// It consumes an http.Response - which it uses to validate the response against "Expects"
// TestCase lifecycle:
//     Create a Testcase Object
//     Create / retrieve the http request object
//     Apply context information to the request object
//     Rule - manages passing the request object from the testcase to an appropriate endpoint handler (like the proxy)
//     Rule - receives http response from endpoint and provides it back to testcase
//     Testcase evaluates the http response object using its 'Expects' clause
//     Testcase passes or fails depending on the 'Expects' outcome
creates an HTTP request for this test case
The reason why we're doing this is that a testcase behaves like an http object
It produces an http.Request - which can be sent to a server
It consumes an http.Response - which it uses to validate the response against "Expects"
TestCase lifecycle:
Create a Testcase Object
Create / retrieve the http request object
Apply context information to the request object
Rule - manages passing the request object from the testcase to an appropriate endpoint handler (like the proxy)
Rule - receives http response from endpoint and provides it back to testcase
Testcase evaluates the http response object using its 'Expects' clause
Testcase passes or fails depending on the 'Expects' outcome
// ApplyInput - creates an HTTP request for this test case // The reason why we ' re doing this is that a testcase behaves like an http object // It produces an http . Request - which can be sent to a server // It consumes an http . Response - which it uses to validate the response against " Expects " // TestCase lifecycle : // Create a Testcase Object // Create / retrieve the http request object // Apply context information to the request object // Rule - manages passing the request object from the testcase to an appropriate endpoint handler ( like the proxy ) // Rule - receives http response from endpoint and provides it back to testcase // Testcase evaluates the http response object using its ' Expects ' clause // Testcase passes or fails depending on the ' Expects ' outcome
func (t *TestCase) ApplyInput(rulectx *Context) (*resty.Request, error) {
	if t.Input.Method == "" {
		return nil, t.AppErr("error: TestCase input cannot have empty input.Method")
	}
	req, err := t.Input.CreateRequest(t, rulectx)
	if err != nil {
		return nil, t.AppErr("createRequest: " + err.Error())
	}
	t.Request = req 
	return req, err
}
func ( t * TestCase ) ApplyInput ( rulectx * Context ) ( * resty . Request , error ) { if t . Input . Method == " " { return nil , t . AppErr ( " " ) } req , err := t . Input . CreateRequest ( t , rulectx ) if err != nil { return nil , t . AppErr ( " " + err . Error ( ) ) } t . Request = req return req , err }
creates an HTTP request for this test case
The reason why we're doing this is that a testcase behaves like an http object
It produces an http.Request - which can be sent to a server
It consumes an http.Response - which it uses to validate the response against "Expects"
TestCase lifecycle:
Create a Testcase Object
Create / retrieve the http request object
Apply context information to the request object
Rule - manages passing the request object from the testcase to an appropriate endpoint handler (like the proxy)
Rule - receives http response from endpoint and provides it back to testcase
Testcase evaluates the http response object using its 'Expects' clause
Testcase passes or fails depending on the 'Expects' outcome
creates an HTTP request for this test case The reason why we ' re doing this is that a testcase behaves like an http object It produces an http . Request - which can be sent to a server It consumes an http . Response - which it uses to validate the response against " Expects " TestCase lifecycle : Create a Testcase Object Create / retrieve the http request object Apply context information to the request object Rule - manages passing the request object from the testcase to an appropriate endpoint handler ( like the proxy ) Rule - receives http response from endpoint and provides it back to testcase Testcase evaluates the http response object using its ' Expects ' clause Testcase passes or fails depending on the ' Expects ' outcome
// store the request in the testcase