You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Intergation tests are powerful becuase they allow testing the dark parts of the engine. Migrations are one of the darkest corners.
Two proposed tests:
Undo all migrations without failures - This proves that we can undo. But it doesn't promise anything about the logic
Ensure that migration is logically correct - Assuming that in v0.1 the field order.hasSupportTickets is optional and for some records it is null. Then in v0.2 this field is mandatory + New logic is presented: If this field is true, an order can not be deleted. The migration should set all NULL fields to true. A Typical test will insert records where this field is set (not null), it not even possible to insert an empty hasSupportTickets column because v0.2 doesn't allow this. But, in production for some rows it's null as they were inserted previously!
We can test this with:
test('When older Order record exist with empty hasSupportTickets and trying to delete it, then deletion fails with HTTP 409', () => {
// Arrange
migrate the DB to v0.1
insert an order with empty hasSupportTickets
migrate the DB to v0.2
// Act
try to delete the order
// Assert
...
}
The text was updated successfully, but these errors were encountered:
Intergation tests are powerful becuase they allow testing the dark parts of the engine. Migrations are one of the darkest corners.
Two proposed tests:
We can test this with:
test('When older Order record exist with empty hasSupportTickets and trying to delete it, then deletion fails with HTTP 409', () => {
// Arrange
migrate the DB to v0.1
insert an order with empty hasSupportTickets
migrate the DB to v0.2
// Act
try to delete the order
// Assert
...
}
The text was updated successfully, but these errors were encountered: