Eric Saxby

Founder @ Reflective Software

Eric came to programming after wandering through a number of other fields and attempts at careers. After a decade of Ruby development he made the jump to Elixir, and has not looked back since. In the past few years he has mostly worked on high-volume data processing applications, though he also cares about appearances and can spend hours tweaking typographical styles.

Away from computers, he loves playing music, practicing martial arts, snuggling with cats, and in general being around people who care about what they do.

Talk:
Acceptable Upgrades

Level: Intermediate

How do you upgrade a legacy application written around a legacy database—databases designed with best practices from the 90s, with UML looking somewhere between abstract expressionism and piles of spaghetti? …But keep the tests small and understandable, please!

In my experience, people write tests in 3 cases: they’re too stubborn not to; their problems are too complex to solve without them; or their setup is so understandable that there’s no reason not to. When working on large untested applications, it’s very easy to skip tests—there’s too much precedent to want to slow down and fight against the current.

Here, I will share patterns and experiments that help to write tests faster—and show that with good tooling you can fight upstream to make it so that you can maintain systems and update them with confidence.

OBJECTIVES:

  • I would like for more people to test their code, if only because it’s frustrating to use websites that crash all the time. Over the past eight years of using Phoenix, LiveView, and Ecto, as well as in building lots of Elixir libraries, I’ve fought with tests at least as much as I’ve fought with code. In doing so, I’ve developed patterns for interacting with Phoenix, Ecto, application config, global state… etc.
  • I’d also like more people to contribute to an ecosystem of libraries and patterns to help others test their libraries and applications.

AUDIENCE: Anybody who wants to write better tested code, or who manages projects that they want to be better tested.