What are Service Acceptance Tests?

What are Acceptance Tests for Services?

Understanding Acceptance Tests

• Acceptance tests for services are similar to UI acceptance tests but focus on system interaction through the server rather than the graphical interface.

• In UI acceptance testing, both the tester and test observe interactions with the system's graphical interface, while service acceptance tests involve sending requests directly to the server.

Importance of Both Testing Types

• Two main reasons exist for needing both types of acceptance tests: ensuring functionality for human users and other systems that utilize these services.

• Systems like Twitter serve as examples where users interact via a GUI, while other systems may access Twitter's services programmatically to analyze sentiment or gather data.

Contextual Considerations in Testing

• It's crucial to consider context when determining if service acceptance tests are necessary; if a system is solely used through GUIs by humans, less emphasis may be needed on service testing.

• The second reason for conducting service acceptance tests is their ability to help locate issues more effectively when failures occur in client-side testing.

How Service Acceptance Tests Aid in Problem Localization

Identifying Issues Through Testing

• When a client-side test fails, it can be unclear whether the issue lies within the client code, communication between client and server, or server code itself.

• Running both client-side and service acceptance tests helps narrow down potential problem areas; if both fail, it's likely an issue with the server.

Evidence from Test Results

• If a service test fails alongside a client test, it indicates that problems likely reside on the server side. Conversely, if only the client test fails while the service test passes, this suggests issues lie within the client's code or its communication with the server.

Example of Service Acceptance Testing

Framework for Service Tests

Understanding System Interface and Service Requests

Overview of System Interaction

• The discussion begins with a focus on the graphical interface of the system, emphasizing that the primary concern is the services rather than the visual elements.

• It highlights that there are no students registered with CPF 683, leading to a request for student registration details, specifically for Paulo with CPF 683.

• The text clarifies that steps reference the internal state of the server rather than what is displayed in the graphical interface.

Implementation Details

• The implementation does not refer to GUI elements like filling fields or clicking buttons; instead, it focuses on sending service requests to the server and analyzing responses.

• A GET request is sent to check if any student exists with CPF 683. This involves constructing a URL based on the server's address.

Request Handling

• There’s no guarantee that requests will succeed; they return promises of responses which need to be analyzed for success.

• If successful, a response body containing JSON data is expected. This body will include attributes such as CPF.

Response Verification

• The response body must include specific data (CPF 683), indicating whether a student already exists in the system.

• If this attribute is absent from the response, it confirms that no student with that CPF is registered.

Test Assumptions and Conditions

• The implementation assumes each test starts with an empty state where no students are registered.

• If tests were conducted without resetting conditions, additional actions would be necessary to ensure accurate testing states (e.g., deleting existing records).

Diagrammatic Representation

• A diagram illustrates how tests may require initial actions to set up valid preconditions before executing checks against postconditions.

• It emphasizes that sometimes systems must be manipulated into specific states before validation can occur effectively.

Acceptance Testing Insights

• Acceptance tests evaluate both preconditions and postconditions within system interactions, ensuring functionality aligns with expectations after operations are performed.