Monday Morning Me

I’ve skipped a few Monday Morning Me’s due to Ruby DCamp and a couple of other things. DCamp was awesome, and maybe beyond my humble ability to do a trip report. In the meantime..

Rails Test Prescriptions

Ground has been broken and progress is being made. Not a lot of ground, and not a lot of progress, but ground and progress nevertheless. So, yay, that.

When last I wrote about this, I was debating whether to use MiniTest or RSpec as the main test framework for the book. After a couple of impassioned pro-MiniTest pleas at Ruby DCamp last week, I’ve come around to the idea that MiniTest’s availability and simplicity trump RSpec’s mindshare and ecosystem, at lest for teaching purposes.

However…

The first real code section of Rails Test Prescriptions is a TDD walkthrough of adding a first feature to a new project.

One of the guiding principles of the book is that I want the advice and techniques to reflect effective practice, or at least effective practice as I understand it.

My normal practice for adding a new feature would be an outside-in approach: write an end-to-end test describing the new behavior, then fill in logic with focused unit tests. Normally, I would use Cucumber and RSpec for this. But, as mentioned, the book is using MiniTest instead of RSpec. And I don’t want to bring Cucumber in right at the beginning for similar reasons — too much to explain.

Which leaves me writing end-to-end tests using Rails integration tests (ugh) or Capybara, which, of course, also involves bringing in a new gem. Which I’m doing, but the Capybara MiniTest gem wants to use the MiniSpec syntax, which I don’t want to use because more explaining of details early on and all. ( Update Mike Moore points out that I’m overstating the extent to which Capybara MiniTest wants to use MiniSpec as opposed to allows MiniSpec. I still am not sure that a lot of people are actually using MiniTest/no spec syntax/capybara.)

So it occurs to me that in the guise of coming up with a testing stack that will make sense to testing novices I have stumbled with the best of intentions into a set of libraries that as far as I can tell is in active use by effectively nobody in the entire world.

This is either insane, or so sane that it’s amazing. Statistically, the odds are on insane, but I’d love a second opinion.

It seems like my viable options are:

• Do what I’m doing and assume that I can explain it well enough to make sense.
• Back out and use Rails integration tests instead of Capybara
• Back out and use RSpec instead of MiniTest
• Back out and write the Angular book instead. (This is not really an option)

I’m open to comments if you have a suggestion.

Other than that, it’s just been a matter of getting used to changes in the build tools, and finding an editor setup that plays nicely with the formats that Prag uses. Nothing too bad, though I’m seriously considering that Editorial on the iPad has a real shot of becoming my primary editor for this book (writing it on the iPad next to coding on my laptop). Which is also clearly so insane that it may lap all the way around and become sane again.

Trust-Driven Development

Obviously, I’ve missed my plan to get something out in September. I have about 30 some odd pages of text, and I’d release it except that some of the sections kind of trail off in mid paragraph. I may just release it anyway, I have a beta reader or two looking at the manuscript to answer that very question.

If you want slightly earlier access, let me know via email (noel at noelrappin dot com). And, of course, you can by what exists of the book at /trdd.

Mastering Space and Time

So sales have started to pick up at the new price level. Not setting the world on fire or anything, but a more steady rate. Let me know if you are interested in writing about Master Space and time in JavaScript on your blog or something. And, the book is still available at /mstwjs.