Project Functional Testing

For purposes of this API description, all URLs are relative to the base url of http://localhost:8080/parkpay

The JSON used for testing purposes will match the format described in the project API.

Functional testing will begin only after the tester was able to build the project following your build instructions and then deploy the resulting .war file to a tomcat server. If your build scripts generate something else other than a .war file that's fine too, as long as the build & deploy instructions are clear and work as expected.

The specific actions taken by the tester before beginning functional acceptance testing are described here.

Values (in the expected response files) that are enclosed between angle brackets will be substituted with actual values we recorded in the previous testing steps. For example, if you see in the expected response "pid": "<pid1>" it means that the test will expect to see something like "pid": "79" when it runs, where 79 is the value that was returned in a previous response that we denoted as pid1.

If you think that what you see below is a lot of testing, then you should consider the fact that we're just scratching the surface testing: for instance, we have very few tests that validate how your application responds to invalid data in the request, and only one test for submitting requests that violate application logic. In fact, all the tests below represent a pretty minimalistic set of tests.

Below are the steps we'll take to test the functionality of your project.

NOTE: the testers reserve the right to do more extensive testing than the tests below, by either adding more tests or by changing the request payloads.

Lastly, your TA has developed a script that automates the testing of your project. The script takes performs the actions described in each test (GET, POST, PUT, DELETE) using the payload that needs to be submitted, aas needed, and compares the output returned by your application with the expected output. Read more about how to run the script.

Download the data to be submitted and expected responses here

1. Validate that there are no parks to be returned when the applicatin runs for the first time ( GET /parks ). The response should be an empty JSON array.
2. Verify that bad data POST-ed ( POST /parks ) in order to create a park will return a 400 (Bad Request) error. View the data for the POST. Here is the expected response.
3. Create a park ( POST /parks ) using valid data. The request should return 201 (Created) and the HTTP header should contain a 'Location' header with link to /parks/<pid1>. View data for the POST. Here is the expected response.
4. Verify that the park has been properly created ( GET /parks/<pid1> ). Here is the expected response.
5. Update park <pid1> ( PUT /parks/<pid1> ). View data for the PUT. The HTTP response should be 204 (No content) with an empty body.
6. Create a new park ( POST /parks ). This will be known as <pid2>. View data for the POST. Here is the expected response.
7. Create a third park ( POST /parks ). This will be known as <pid3>. View data for the POST. Here is the expected response.
8. Verify that there are three parks ( GET /parks ). Here is the expected response.
9. Search parks ( GET /parks?key=south ). Here is the expected response.
10. Delete park <pid2> ( DELETE /parks/<pid2> ). The HTTP response should be 204 (No content) with an empty body.
11. Attempt to delete park <pid2> again ( DELETE /parks/<pid2> ). The HTTP response should be 404 (Not Found) with an empty body.
12. Check what parks are still in the system -- there should be two -- by doing a search that is expected to return all parks. ( GET /parks?key= ). Here is the expected response.
13. Create an order ( POST /orders ). It will be identified as <oid1> The date when the order is placed is the date when testing takes place and will be identified as <date-oid1> in subsequent tests. The request should return 201 (Created) and the HTTP header should contain a 'Location' header with link to /orders/<oid1>. View data for the POST. Here is the expected response.
14. View all orders ( GET /orders ). Here is the expected response.
15. Verify that a visitor has been created when the order was placed ( GET /visitors ). The ID of this visitor is <vid1>. Here is the expected response.
16. View the detail for visitor <vid1> ( GET /visitors/vid1 ). Here is the expected response.
17. Create a note as visitor <vid1> and try to associate it with park <pid1> ( POST /parks/<pid1>/notes ). Since <vid1> has not placed an order with park <pid1> (instead he placed an order with <pid3>), the request will return a 400 (Bad Request) HTTP status code. View data for the POST. Here is the expected response.
18. Create a note as visitor <vid1> and associate it with park <pid3> ( POST /parks/<pid3>/notes ). The note will be known as <nid1> View data for the POST. Here is the expected response.
19. View again the detail for visitor <vid1> ( GET /visitors/vid1 ). Here is the expected response.
20. View note <nid1> ( GET /notes/nid1 ). Here is the expected response.
21. Create a new order ( POST /orders ). It will be identified as <oid2> The date when the order is placed is the date when testing takes place and will be identified as <date-oid2> in subsequent tests. The request should return 201 (Created) and the HTTP header should contain a 'Location' header with link to /orders/<oid2>. View data for the POST. Here is the expected response.
22. Create a new order ( POST /orders ). It will be identified as <oid3> The date when the order is placed is the date when testing takes place and will be identified as <date-oid3> in subsequent tests. The request should return 201 (Created) and the HTTP header should contain a 'Location' header with link to /orders/<oid3>. View data for the POST. Here is the expected response.
23. Verify all visitors ( GET /visitors ). Here is the expected response. Make a note of <vid2> as it will be used in the next test.
24. Create a note as visitor <vid2> and associate it with park <pid3> ( POST /parks/<pid3>/notes ). The note will be known as <nid2> View data for the POST. Here is the expected response.
25. View all notes for park <pid3> ( GET /parks/pid3/notes ). Here is the expected response.
26. View note <nid2> for park <pid3> ( GET /parks/pid3/notes/nid2 ). Here is the expected response.
27. View order <oid3> ( GET /orders/oid3 ). Here is the expected response. NOTE: the format for the value of "date_and_time" should be "YYYY-MM-DDTHH:MM:SS.MSZ", as described in the Project API document.
28. View all orders ( GET /orders ). Here is the expected response.
29. Search orders ( GET /orders?key=60MPG ) Here is the expected response.
30. Search visitors ( GET /visitors?key=john ). Here is the expected response.
31. View available reports ( GET /reports ). Make a note of <rid1> (Admissions report) and <rid2> (Revenue report). Here is the expected response.
32. Get admissions report ( GET /reports/rid1 ). Here is the expected response.
33. Generate admissions report with some date filtering ( GET /reports/rid1?end_date=20171231 ). Here is the expected response.
34. Get revenue report ( GET /reports/rid2 ). Here is the expected response.
35. Check how the revenue report handles an invalid date ( GET /reports/rid2?end_date=20171232 ). The HTTP status code should be 400 (Bad Request). Here is the expected body of the response.