Modern user interfaces, especially MacOS and iOS, have lots of “casual” animation -- views that appear through brief animated sequences largely orchestrated by the system.

```
[[myNewView animator] setFrame: rect]

```

Occasionally, we might have a slightly more elaborate animation, something with an animation group and a completion block.

Now, I can imagine bug reports like this:

> 
> Hey -- that nice animation when myNewView appears isn't happening in the new release!
> 
> 
> 

So, we'd want unit tests to do some simple things:

* confirm that the animation happens
* check the duration of the animation
* check the frame rate of the animation

But of course all these tests have to be simple to write and mustn't make the code worse; we don’t want to spoil the simplicity of the implicit animations with a ton of test-driven complexity!

So, **what is a TDD-friendly approach to implementing tests for casual animations?**

---

Justifications for unit testing
-------------------------------

Let's take a concrete example to illustrate why we'd want a unit test. Let's say we have a view that contains a bunch of WidgetViews. When the user makes a new Widget by double-clicking, it’s supposed to initially appear tiny and transparent, expanding to full size during the animation.

Now, it's true that we don't want to need to unit test system behavior. But here are some things that might go wrong because we fouled things up:

1. The animation is called on the wrong thread, and doesn't get drawn. But in the course of the animation, we call setNeedsDisplay, so eventually the widget gets drawn.
2. We're recycling disused widgets from a pool of discarded WidgetControllers. NEW WidgetViews are initially transparent, but some views in the recycle pool are still opaque. So the fade doesn't happen.
3. Some additional animation starts on the new widget before the animation finishes. As a result, the widget begins to appear, and then starts jerking and flashing briefly before it settles down.
4. You made a change to the widget's drawRect: method, and the new drawRect is slow. The old animation was fine, but now it's a mess.

All of these are going to show up in your support log as, "The create-widget animation isn't working anymore." And my experience has been that, once you get used to an animation, it’s really hard for the developer to notice right away that an unrelated change has broken the animation. That's a recipe for unit testing, right?