Recently, we had an interesting request from one of our clients where we needed to implement time travel for testing purposes - or fake time travel at least! The Quality Assurance (QA) team of one of our clients wanted to test functionality under particular time constraints within their application. To do that, they needed is to move the application’s internal clock to check and see whether some these time-based actions were allowed or forbidden (depending on the case). Mocking up operating system’s datetime settings on Heroku was the answer, with setting up environmental variables for datetime testing. Heroku datetime testing in a Ruby on Rails application required a little configuration - but we were able to get the job done.
Because the QA team tests full scenarios (using the web interface), we had to ensure that the time remained consistent between multiple requests, so when objects were saved to the database they stored the correct time with them (i.e. Rails’ timestamps).
Libfaketime to the rescue
Since we needed to modify the time for the Ruby process, we decided to use the libfaketime library. The library works by intercepting various system calls that programs might use to retrieve the current date and time. Thanks to libfaketime, we can easily modify the date & time just for our application’s processes (Puma and Rails, Sidekiq, workers, etc.) without affecting other applications running on the same machine.
Note: Since it relies on the library preload mechanism of the operating system, there are some cases when it might not work (check the Compatibility issues section of the
libfaketime README), but we didn’t spot a case where it wouldn’t work in our Rails application.
Libfaketime is 3rd party library, you just need to install it (
configure, make, make install) and you are ready to go. Or are you? Ah, we forgot to mention that our client is using Heroku…
Heroku custom buildpack
If you were using a VPS or self-hosted solution, then you would just install the libfaketime library globally and then modify the processes that need custom time. On Heroku, it’s not quite that easy - if you need to modify the container’s configuration / environment for your app, you need to use buildpack for that.
This means that in order to make
libfaketime available, we had to create a buildpack that downloads it and compiles it during the build. We also had to modify the running processes to be wrapped with
However, building a custom Heroku buildpack is a topic for another blog post. Here we will just show how we wrap running processes with
libfaketime without modifying the
Setting up libfaketime on Heroku
Every Linux system supports the
LD_PRELOAD env variable. It can contain one or more paths to shared libraries, which may be injected before any other shared library (including the C runtime). Since Heroku heavily relies on environment variables for dyno configurations, it sounded like the perfect solution for us - and indeed it was ;)
So! To get things ready to play with time, we need to set 2 environment variables and use a buildpack to modify the time in the Ruby on Rails application:
LD_PRELOADwith path set to the
libfaketime1.sofile for injecting
FAKE_TIMEwith the relative date to modify the current time
Note: We relied on relative date to simulate time passing. If you specify
FAKE_TIME to an absolute value (i.e.
2020-12-24 20:30:00) all your further calls to
Time.now will return the same date and time.
Since the project already had a dedicated user interface for the QA team to manage testing scenarios (i.e. create new users, etc.), we included a ‘Time travel’ component to it. But how can you modify the environment of a running application if it’s already running? By using Heroku’s API!
Heroku provides a platform-gem which allows you to interact with any Heroku application (i.e. updating environment variables, managing add-ons, builds and more), where any change to environment variables on Heroku results in immediate container restarts (to pickup the change). Very handy! With the platform-gem we connected a simple date picker with an environment variable (
FAKETIME) value on Heroku. After approximately 30 seconds (time to fully restart Heroku dynos) from the change (using the UI) the QA team was able to move in time. Easy way to conduct time travel testing, right?
It’s always a pleasure making a QA team’s life easier. If you are interested in building more robust testing solutions that help out your QA team then come and speak to us! iRonin can help your project become stronger and better tested than ever before.