As with any development, test-driving features is the way to go in a Flux app. As I’ve been learning this technology, I’ve been collecting some of the less obvious patterns that make testing easier. In this post, we’ll take a look at some of these strategies, to make it easier for you to build the next big thing.
The other day at our company standup, I mentioned that I was eager to
read an article on Concurrency in Minitest
that was featured in Ruby Weekly. One of my
coworkers asked: "people still use Minitest?" My reply: "you mean you're not using Minitest yet?"
I love Minitest. It's small, lightweight, and ships with Ruby. It's used by respected programmers like Aaron Patterson, Katrina Owen, Sandi Metz, and of course, DHH. Here's a look at why Minitest remains a powerful and popular choice for testing Ruby code.
Time and time again, I talk with someone who writes tests, but they don't feel comfortable/productive writing tests first. First off, writing tests after the fact is 100 times better than not writing tests at all. But, writing tests first does have its benefits, and doesn't have to be difficult. I'm not going to talk about the merits of writing tests first. That debate is all over internet already. This post is for those that write tests and have the desire to write tests first.
I built a wrapper class around HighCharts, so that the rest of my front-end code could operate without knowing the details of the HighCharts API and the details of chart-building.
But how do we unit-test a side-effect-only class, without straying into integration testing or testing the third-party library we're using?