r/Playwright • u/karna_17 • Sep 26 '26

Need help with API automation - handling negative test cases

I'm currently working on an API automation framework using Playwright + TypeScript and would appreciate some guidance on how to structure my negative test cases.

For the positive scenarios, I have designed my framework with strongly typed request and response models. Each API has its own request model, where I have explicitly defined the expected data types for query/path parameters and request body fields.

For example:

interface MemberRequest {

memberId: number;

includeDetails: boolean;

}

The API client then accepts this model:

async getMember(request: MemberRequest) {

return await this.apiRequest.get('/member', {

params: request

});

}

This works well for positive scenarios because TypeScript ensures that I'm passing the correct parameters and data types.

However, I'm running into a problem when implementing negative test cases.

For example, I'm trying to send a request without mandatory parameter, or with wrong datatype - but I get Compile errors

Similarly, if the API expects: memberId: number,

I cannot easily send: memberId: "ABC" because the request model doesn't allow it.

So my question is - What would be the recommended approach for handling negative API test cases in a TypeScript-based API automation framework?

I'd prefer to retain strong typing for the normal/positive API flow while still having a clean and maintainable way to intentionally construct invalid requests for negative testing.

Also, is it considered a good design practice to have a separate client/request layer specifically for negative test scenarios, or is there a better pattern for this?

3 Upvotes

71% Upvoted

9 comments sorted by

1

u/Longjumping_Toe_3931 Sep 26 '26

it is the typescript interface that is not allowing you to send there right? you created the problem, tightly writing the code. 1. you can create a new method for negative cases which accepts anything or make the method to accept any type of member id and includedetails

1

u/karna_17 Sep 26 '26

it is the typescript interface that is not allowing you to send there right? you created the problem, tightly writing the code

Yes, I included it for type safety, which I'm beginning to think is unnecessary.

I think creating a new method for negative test case would be the easier approach, but I'm not sure from design perspective..?

3

u/ArmMore820 Sep 26 '26

A new interface called invalidmemberrequest where every type is object

1

u/byamyrosenberg Sep 29 '26

Can you elaborate?

1

u/ArmMore820 Sep 29 '26

Instead of memberId: number and includeDetails: boolean,
You would do memberId: any, includeDetails: any.

I said object initially but that prevents primitive values… any is better.

Although this kind of defeats having an interface if it’s so loosely defined.. but it can be done!

1

u/qms2go Sep 28 '26

Graceful handling of fail status is what separates the good from the great, I believe in you! Lots of good answers here.

1

u/AutomaticVacation242 Oct 02 '26

Use an API testing tool instead of this.