The next challenge is defining functionality that depends on two points in time, especially rules relative to current time.
Describing time-based rules is tricky, since time is usually relative, and relative rules often lack precision. If an account payment needs to be sent on the same day each month, but the initial payment was on the 30th January, the meaning of “same day next month” is up for discussion.
Another problem with time rules comes from the need to automate tests based on the examples. We rarely have the luxury of pausing the test for the time to actually pass. Forex rates may need to be updated once a day, but tests for the update functionality need to run in milliseconds to be effective. Waiting until tomorrow to learn if the test passed or failed is not really an option.
For the next challenge, consider a common feature with credit card processing: cancelling uncharged authorisations.
Card transactions usually go through two states: authorised and charged. In the “authorised” state, the client’s bank reserves the amount, but does not actually take it from the client account. Once the merchant receives an authorisation, they can “charge” it at some point in the future, usually up to a month. For online digital services, an authorisation is typically charged within a few seconds. For physical goods, merchants might authorise a transaction first, then charge it only when the item physically ships days later.
To avoid locking up client funds indefinitely, banks will cancel an authorisation if it has not been charged for a month. That’s what all the scenarios below are trying to describe.
Option 1: “TODAY” replaced with current date by the automation layer
Given a transaction is authorised on TODAY - 1 month And the transaction was not charged When the cancellation job runs for TODAY Then the authorisation should be cancelled
Option 2: hard-coded dates
Given a transaction is authorised on 8 October 2020 And the transaction was not charged When the cancellation job runs for 9 November 2020 Then the authorisation should be cancelled
Option 3: implied current date
Given a transaction was authorised more than a month ago And the transaction was not charged When the cancellation job runs Then the authorisation should be cancelled
Option 4: explicitly setting the active time
Given the current time is 2020-10-09T14:27:46.000Z And a transaction is authorised When the current time is 2020-11-09T14:27:46.001Z And the transaction was not charged And the cancellation job runs Then the authorisation should be cancelled
PS: … and don’t forget to share the challenge with your friends and team members by clicking on one of the social icons below 👇