Project Functional Testing

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

The JSON used for testing purposes will match the format desribed 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. The specific actions taken by the tester before beginning functional acceptance testing are described here.

NOTE: IF your REST delivery is not based on servlets, then you may ignore the part where we say that we "deploy the resulting .war file to a tomcat server". However, we'll still require you to have a script that builds and deploys the project to a runtime environment.

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 "sid": "<sid1>" it means that the test will expect to see something like "sid": "79" when it runs, where 79 is the value that was returned in a previous response and we denoted as sid1.

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 do not have any test that validates how your application responds to invalid data in the request, e.g., nor do we have any test for submitting requests that violate application logic, such as submitting an order with seating in different sections. In fact, all the tests below represent a pretty minimalistic set of tests.

Lastly, we have created an automated test script that you can download here. Download the file in your test environment (Ubuntu 16.04), unzip, change your working directory to CS-445-project_test ( cd CS-445-project_test ) and then read the readme.txt file for details.

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

1. Validate the seating in the theatre ( GET /seating ). The JSON file that describes the theatre layout is here and is based on this theatre layout picture. You can view the expected response in this file. Write down the value for "sid" for the section named "Front right", we'll call this value sid1. Also write down the values for "sid" for the sections named "Front center" and "Front left", we'll call these values sid2 and sid3 respectively. NOTE: the values for "sid" returned by the application being tested my be different from the values in the file.
2. Verify the seating layout for section sid1 ( GET /seating/sid1 ). The expected response is here. NOTE: the actual value for "sid" will be sid1, as noted in the previous step.
3. Verify that there are no shows ( GET /shows ). View expected JSON.
4. Create a show ( POST /shows ). Note the value of "wid" in the body of the response, this is wid1. View the data for the POST.
5. View all the shows: there should be just one. ( GET /shows ). Here is the expected response.
6. Verify the show detail for wid1 ( GET /shows/wid1 ). View the expected response.
7. Update the show wid1 ( PUT /shows/wid1 ). View the data to be PUT.
8. Verify the show detail for wid1 ( GET /shows/wid1 ). View the expected response.
9. View the sections available for show wid1 ( GET /shows/wid1/sections). The expected JSON response is here.
10. Validate seating in section sid1 for show wid1 ( GET /shows/wid1/sections/sid1 ). View the expected response. Write down the "cid" values for row #1, from left to right: cid2, cid2, cid3, cid4. Also wite down the "cid values for row #2: cid5, cid6, cid7, cid8. NOTE: the values for "cid" may be different from the ones in the sample response.
11. Request a number of contiguous seats that cannot be found in section sid1 ("Front left") ( GET /seating?show=wid1&section=sid1&count=5 ). View the expected response.
12. Request a number of contiguous seats that can be accomodated by section sid1 ( GET /seating?show=wid1&section=sid1&count=4 ). You can view the expected response here. NOTE: the values for "starting_seat_id" and "cid" may be different from the ones in the sample response.
13. Request a number of contigious seats starting with a specific seat in the section ( GET /seating?show=wid1&section=sid1&count=3&starting_seat_id=cid2 ). View the expected response.
14. Test another request for contiguous seats starting with a specific seat ( GET /seating?show=wid1&section=sid1&count=4&starting_seat_id=cid2 ). There aren't enough seats in the first row to accomodate the request, hence the seats will come from row #2. The expected response is here.
15. Create an order ( POST /orders ). You can find view the body of the POST request in this file and the expected response here. Write down the value of "oid", this will be oid1. Also write down the ticket IDs (the values in the "tickets" array) as tid1, tid2, and tid3. NOTE: the values for "oid", the ticket IDs, and "date_ordered" may be different from the sample response.
16. Verify that the order has been created ( GET /orders ). There should be only one order in the reponse. View the expected response.
17. Verify that the order detail for oid1 is correct ( GET /orders/oid1 ). The expected response from your application is here.
18. Create another order ( POST /orders ). This is oid2. The body of the POST request is here. You can also view the expected response.
19. Request seating information for section sid2 ("Front center") for show wid1 ( GET /shows/wid1/sections/sid2 ). View the expected response. Write down the "cid" values for row #1, from left to right: cid9, cid10, cid11, cid12. NOTE: the values for "cid" may be different from the ones in the sample response.
20. Create a third order ( POST /orders ). This is oid3. The body of the POST request is here. You can also view the expected response.
21. Validate the seating in section sid1 for show wid1 ( GET /shows/wid1/sections/sid1 ). View the expected response.
22. Get orders by date ( GET /orders?start_date=YYYYMMDD&end_date=YYYYMMDD ) where YYYYMMDD is the day when the test script is being run. Here is the expected response.
23. Subscribe to receive one donated ticket ( POST /shows/wid1/donations ) for show wid1. Write down the value of "did" in the body of the response; this will be did1. View the body of the POST request and the expected response. NOTE: the value for "did" may be different from the one in the sample response.
24. Subscribe to receive two donated tickets ( POST /shows/wid1/donations ) for show wid1. Write down the value of "did" in the body of the response; this will be did2. View the body of the POST request.
25. Check the status of the first subscription ( GET /shows/wid1/donations/did1 ). You can view the expected response here.
26. Check the status of the second subscription ( GET /shows/wid1/donations/did2 ). You can view the expected response here.
27. Donate two (2) tickets ( POST /tickets/donations ). View the body of the POST request.
28. Check the status of the first subscription ( GET /shows/wid1/donations/did1 ). You can view the expected response here.
29. Check the status of the second subscription ( GET /shows/wid1/donations/did2 ). You can view the expected response here.
30. Verify the detail of order oid1 ( GET /orders/oid1 ). The expected response from your application is here.
31. Get list of available reports ( GET /reports ). View the expected response. Write down the values for "mrid" as follows, mrid1 for "Theatre occupancy", mrid2 for "Revenue from ticket sales", and mrid3 for "Donated tickets report".
32. Run mrid2 for show wid1 ( GET /reports/mrid2?show=wid1 ) and validate the results by comparing with the expected response.
33. Search for order oid1 ( GET /search?topic=order&key=oid1 ). View the expected response.