BDD Testing Time

Automated software testing with time is tricky, even more so in BDD style Acceptance Tests. In this video Dave Farley explores some useful and powerful techniques for managing time in Behavior Driven Development (BDD) style tests.

So how can you take control of that slipperiest of variables - Time, and 'Time Travel' in Behaviour Driven Development testing, or indeed in any automated tests?

--------------------------------------------------------------------------------------

If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses:

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble

--------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------



---------------------------------------------------------------------------------------

Useful Books on this topic:
(Please note, if you buy a book from these links I get a small fee, without increasing the cost to you)

[kclarky]

Got into your channel via your cyberpunk video as Im sure many other will have done, could I suggest in addition to the mailing list you set up a discord server for those of us struggling with the thorny issues of transformation to CI/CD from deep legacy

[JavierPortillo]

In languages that can't replace inputs like that, would you think is valid to inject a "TimeProvider" that we could double in test to control time?

[tombinns]

My concern about the time travel against a running system (it makes absolutely perfect sense for unit tests) is that it opens up a route to change the time from outside of the system. We could add logic to only open it for test and dev environments but then we'd need a test in prod to make sure it was disabled.

The way I've dealt with this in the past is to add the time element as a config item, e.g. OVERDUE_AFTER, and deploy a specific version of the SUT with this set to a low value. It's not ideal but it feels safer to me. Especially as the logic will have been tested thoroughly at unit test level.

[pappont]

Agree. In Java I never execute Instant.now() or similar methods. Better create java.time.Clock object, inject it and execute Instant.now(clock)