It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Analyze the database logic and test each set of inputs that can change the behavior.
There's not much to say about the first option. For the second, think of an API endpoint that creates a reservation for a hotel room. Your tests should initialize the database with one or more users and one or more rooms (shameless plug: I wrote a thing that makes that a lot more manageable).
Your basic test: given I already have users and rooms, I should be able to pass a request body with a user id, room id, and check in/out dates to my endpoint. After a successful request, I can retrieve a record from reservations matching my parameters. Access the database directly for setup and verification, but otherwise treat it as a "black box" and make sure you think through the different paths your logic takes based on the inputs you pass it.
You have a couple of options:
There's not much to say about the first option. For the second, think of an API endpoint that creates a reservation for a hotel room. Your tests should initialize the database with one or more
users
and one or morerooms
(shameless plug: I wrote a thing that makes that a lot more manageable).Your basic test: given I already have
users
androoms
, I should be able to pass a request body with a user id, room id, and check in/out dates to my endpoint. After a successful request, I can retrieve a record fromreservations
matching my parameters. Access the database directly for setup and verification, but otherwise treat it as a "black box" and make sure you think through the different paths your logic takes based on the inputs you pass it.Hi Dian
Thank you for your reply.
I was not aware about the concept of fixtures.I will surely look into it.