ProductOpener::APITest - utility functions to interact with API
Wait for dynamic_front to be ready. It's important because the application might fail because of that
Wait for server to be ready. It's important because the application might fail because of that
Wait for server and dynamic front to be ready. Run this at the beginning of every integration test
Reset user agent
Return a user agent
Call API to create a user
Call API to edit a user, see create_user
Login as a user
Get a page of the app
Post a form
Reference of a hash of fields to pass as the form result
Call the API to edit a product. If the product does not exist, it will be created.
Reference of a hash of product fields to pass to the API
Return if a form displays errors
Most forms will return a 200 while displaying an error message. This function assumes error_list.tt.html was used.
Constructs the URL to send the HTTP request to for the API.
Takes in two string arguments, One being the the target and other a prefix. The prefix could be simply the country code (eg: US for America or "World") OR something like ( {country-code}-{language-code} )
An example below $target = "/product/35242200055" $prefix= "world-fr"
Returns the constructed URL for the query
For the example cited above this returns: "http://world-fr.openfoodfacts.localhost/product/35242200055"
Compute "Origin" header for $url
Initialize tests and execute them.
The *.t test files call execute_api_tests() with _FILE_ as the first parameter, and the directories for the tests are derived from it.
The tests are in a structure like this:
my $tests_ref = ( [ { # request description setup => 1, # optional, if set to 1, the request will be executed (e.g. to create a product to test on) but the result content will not be checked # expected status code (defaulting to 200) will still be checked to report setup issues test_case => 'no-body', # test case id, must be unique as it is used to name the expected results file method => 'POST', # defaults to GET subdomain => 'world', # defaults to "world" path => '/api/v3/product/12345678', query_string => '?some_param=some_value&some_other_param=some_other_value' # optional form => { field_name => field_value, .. }, # optional, will not be sent if there is a body headers_in => {header1 => value1}, # optional, headers to add to request body => '{"some_json_field": "some_value"}', # optional, will be fetched in file in needed ua => a LWP::UserAgent object, if a specific user is needed (e.g. with moderator status)
# expected return
expected_status_code => 200, # optional. Defaults to 200
headers => {header1 => value1, } # optional. You may add an undef value to test for the inexistance of a header
response_content_must_match => "regexp" # optional. You may add a case insensitive regexp (e.g. "Product saved") that must be matched
response_content_must_not_match => "regexp" # optional. You may add a case insensitive regexp (e.g. "error") that must not be matched
sort_products_by => "product_name" # optional. You may provide a field to sort the returned products by so that they are in an expected order
}
],
);
If undef we open a new client.
You might need this to test with an authenticated user.
Note: this setting can be overriden for each test case by specifying a "ua" field.
Start monitoring a log file
Defaults to /var/log/apache2/log4perl.log
An object to pass to tail_log_read to read
Return all content written to a log file since last check
Object returned by tail_log_start
Content as a string
Retrieve mails in a log extract
Make mail more easy to search by removing some specific formatting
Especially we replace "3D=" for "=" and join line and their continuation
Reformatted text
Replace parts of mail that varies from tests to tests, and also in a format that's nice in json.
ref to an array of lines of the email
Launch a fake HTTP server.
We use that to simulate Robotoff or any HTTP API in integration tests. As it will be launched on the local backend container, we have to pretend those service URL is on backend:$port.
You can provide a list of responses to simulate real service responses, while requests sent are store for later checks by the tests.
A temporary directory to dump requests
You can retrieve requests, in this directory as req-n.sto
List of responses to send, in right order, for each received request.
If the number of request exceed this list, we will send simple 200 HTTP responses with a json payload.
Hold the reference until you don't need the server
Subprogram which wait till the minion finished its job or if it takes too much time
The name of the task
The timestamp of the creation of the task
The max waiting time for this given task
Returns a list of jobs information associated with the task_name
Note: for each job we return the job information (as returned by the jobs() iterator), not the Minion job object.