- 29.1 Three Grains of Rice
- 29.2 Understanding Has to Grow
- 29.3 First Day Automated Testing
- 29.4 Attempting to Get Automation Started
- 29.5 Struggling with (against) Management
- 29.6 Exploratory Test Automation: Database Record Locking
- 29.7 Lessons Learned from Test Automation in an Embedded Hardware-Software Computer Environment
- 29.8 The Contagious Clock
- 29.9 Flexibility of the Automation System
- 29.10 A Tale of Too Many Tools (and Not Enough Cross-Department Support)
- 29.11 A Success with a Surprising End
- 29.12 Cooperation Can Overcome Resource Limitations
- 29.13 An Automation Process for Large-Scale Success
- 29.14 Test Automation Isn't Always What It Seems
This chapter is from the book
This chapter is from the book
This chapter is from the book
29.8 The Contagious Clock
Jeffrey S. Miller, United States
Developer
Sometimes a good testing idea is contagious. Once it meets one need in your system, other uses may emerge that were quite unexpected when you began.
29.8.1 The Original Clock
I had just been hired at Google as a developer on a project during its preparation for public release. The system under development embedded a timestamp when recording certain events. Depending on how long it had been since the events were recorded, the system needed to present, interpret, or process the events in different ways.
The project had a strong mandate for developers to demonstrate the features they created via automated unit and system tests. As my first development task, I took on the job of designing and coding an application clock to make developer testing of time-based behavior simpler. In production, the application clock follows the system clock, but for testing, it wraps a test clock that can be manipulated to simulate the passing of minutes, hours, or days.
29.8.2 Increasing Usefulness
At first, the application clock was used for automated testing of portions of code encapsulating the core logic for time-dependent features. However, the system under development could be driven as a whole via a scripting language that could simulate one or more users interacting with the system to accomplish a set of tasks. Script-driven system tests were the common property of developers, feature owners, and a team of testing specialists. The testing team used script-driven system tests alongside manual verification to exercise the system in detail before each version was released to production. Soon I helped add commands to the scripting language to control the clock, allowing nonprogrammers to set up scenarios that included the passage of time.
29.8.3 Compelling Push
The original application clock was limited by design so that the clock could never be manipulated in the production system and thereby create troublesome inconsistencies. However, the testing team needed to exercise the system and its features interactively in a staging environment similar to the production setup. However, for testing time-based behavior, sometimes they set up a scenario before a weekend and returned after the weekend to verify the correct behavior. Other times the testing team changed the system clock so that the application would pick up the changed time and demonstrate the desired behavior. Both of these techniques were laborious and error prone, with the system clock manipulation frequently causing side effects that would ruin the test.
At the request of a primary tester and another developer familiar with the application clock, I revisited the application clock design. By this time, the system supported a mechanism for enabling and disabling features in production without having to redeploy a new system binary. This mechanism allowed me to guard the application clock from being manipulated on the actual production servers while allowing the testing team to control time interactively on their own simulated production servers.
29.8.4 Lessons Learned
The main thread of this story follows a version of a software developer’s adage: “Wrap external dependencies.” While the runtime library is normally considered internal, the clock it provides is a service outside the system. When the passage of time is important in system logic, wrapping the clock is a beneficial move.
The unexpected bonus was that adapting to successively larger scopes (isolated code, scripted captive system, interactive deployed system) provided benefit to more and different groups of people and for different types of tests. Although the larger scopes required modestly more architectural plumbing, in each case the wrapped clock fit into configuration systems that had been built to bring other benefits to the system. With hindsight, it would have been better to build them earlier had we known more of the operational and testing uses for the application clock.
I’ve now moved on to other work within the company, but I can see the application clock has been maintained and adapted to fit the system’s new configuration mechanisms. I’m glad it continues to prove useful.