Skip to main content

Unboxing Packages: A Requiem for scheduled_test

Long long ago in the dawning days of Dart, when Futures were new and Streams unknown, Bob saw the need for a package manager to bring the people together. Together he and I spun formless bits into code and wove that code into pub, which even today carries code into the eager hands of Dartisans. In those olden days, we had no modern marvels such as the twins async and await, and our tests grew heavy and graceless under the weight of their chain()s1.

So it was that I came up with an idea for a new way of writing tests. Instead of gluing the steps together with the cumbersome Future API, each step would register an asynchronous callback in a queue. Once all the steps were queued up, the library would run them in order. All the API boilerplate would be hidden away from the user, and the tests would look nice and clean. After honing this technique on pub’s tests, I brought it out into its own package, which I called scheduled_test.

If this whole idea of queuing up tasks and running them later sounds complicated, that’s because it was. scheduled_test did a great job of pushing complexity away from test cases, but in return any infrastructure that ran those test cases got much more complex. You couldn’t just write normal Dart code, you had to make sure to wrap everything in schedule() and allow users to pass in Futures and all sorts of hassle. I had created a better sort of tests, but not one without flaws.

The Beginning of the End

Then in Dart 1.9, support for async and await landed and completely changed the equation. No longer did asynchronous APIs have to involve a mess of nesting and callbacks—even the most Future-heavy tests were free to look like plain old synchronous code with some extra keywords sprinkled on top. The driving purpose of scheduled_test, making asynchronous tests look simple and comprehensible, was now supported by the language itself.

You may then wonder, why didn’t scheduled_test fade into obscurity and disuse fifteen Dart versions ago? You may ask, “Natalie, when you created the new test package, why did you decide to use scheduled_test when it no longer had a purpose?” The answer to these questions is infrastructure.

Over the years we had built up a number of APIs around the core functionality of scheduled_test, and even when that functionality got less relevant the APIs that used it were very useful. We couldn’t migrate old code until we had a good replacement, and even for new code scheduled_test was still the best option for testing files and subprocesses.

The Final Blow

This year2, one of my goals was to finally rid the world of scheduled_test once and for all. This meant buckling down and replacing all the infrastructure we’d built on it over the years with new packages that use nothing more than dart:async and the base test API. It took a lot of work, but I did it. I’m pleased to say that pub no longer uses scheduled_test, nor does test. These were scheduled_test’s biggest users, and they serve as a proof-of-concept for the suitability of its replacements:

  • The scheduled_test/descriptor library, which provided a simple and readable API for creating and validating files and directories, is replaced by the test_descriptor package.

  • The scheduled_test/scheduled_process library, which wrapped dart:io’s Process library to provide better debugging and easier line-by-line access to the standard IO streams, is replaced by the test_process package.

  • The scheduled_test/scheduled_stream library provided a pull-based API for streams which has been replaced by the async package’s StreamQueue class, and the stream matchers have been replaced by a suite of matchers in test itself.

  • The scheduled_test/scheduled_server library, which provided a server that validates and handles individual requests, has been moved to the shelf_test_handler package.

  • The core of scheduled_test may be going away, but it had a few useful features that I salvaged. The test package can now print a message only when a test fails and add tear-downs at runtime, both of which were originally supported in scheduled_test only.

I hope these APIs can be used more widely now that they’re no longer tangled up with scheduled_test. In fact, I encourage you to try them out right away if they seem useful—or write your own libraries if they don’t!


  1. Fun fact: Future.then() used to be called Future.chain()!
  2. Excluding April and parts of March and May, when I was out recovering from surgery. I’m doing great, thanks for asking! 😊

Comments

Popular posts from this blog

Const, Static, Final, Oh my!

Posted by Seth Ladd

(This is an "oldie but a goodie" misc@dartlang.org post originally written by Bob Nystrom. It is being posted here as the explanations still ring true.)

Bob writes:


"static", "final", and "const" mean entirely distinct things in Dart:

"static" means a member is available on the class itself instead of on instances of the class. That's all it means, and it isn't used for anything else. static modifies *members*.

"final" means single-assignment: a final variable or field *must* have an initializer. Once assigned a value, a final variable's value cannot be changed. final modifies *variables*.

"const" has a meaning that's a bit more complex and subtle in Dart. const modifies *values*. You can use it when creating collections, like const [1, 2, 3], and when constructing objects (instead of new) like const Point(2, 3). Here, const means that the object's entire deep state can be determ…

Dart 1.12 Released, with Null-Aware Operators and more

Dart 1.12.0 is now released! It contains the new null-aware operators language feature, and enhancements to pub, Observatory, dartdoc, and much more.

Null-aware operators

The new null-aware operators help you reduce the amount of code required to work with references that are potentially null. This feature is a collection of syntactic sugar for traversing (potentially null) object calls, conditionally setting a variable, and evaluating two (potentially null) expressions.

Click or tap the red Run button below to see them in action.

??

  if null operator. `expr1 ?? expr2` evaluates to `expr1` if not `null`, otherwise `expr2`.


??=

  null-aware assignment. `v ??= expr` causes `v` to be assigned `expr` only if `v` is `null`.

x?.p

  null-aware access. `x?.p` evaluates to `x.p` if `x` is not `null`, otherwise evaluates to `null`.

x?.m()

  null-aware method invocation. `x?.m()` invokes `m` only if `x` is not `null`.

Learn more about Dart's null-aware operators in our Language Tour.

.packages fi…

The new AdWords UI uses Dart — we asked why

Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal. The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now. We asked Joshy Joseph, the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.Q: What exactly did we launch on Monday?It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material Design look and f…