Admin frameworks and TDD?

So a few question have come up while building a few apps recently. I’m curious how the developers at thoughtbot handle this.

How do admin/CMS frameworks fit into strong TDD practices?

Here are some example CMS/Admin frameworks:

1 Like

Hello Jared,

Admin frameworks are something that we’ve largely struggled with. Upcase and Exercises are great examples. Upcase uses Rails Admin with no test coverage for the provided functionality. Unfortunately we’ve had failures and regressions due to this.

The exercises app on the other hand uses custom admin pages with test coverage: I have more faith in this admin, but it is obviously more effort to maintain and does not have all the functionality we would get from an configuration driven admin framework.

The most recent Weekly Iteration on the Flashcards feature contains a discussion of our choice to implement a custom admin for Flashcards in the Upcase repo despite having Rails Admin available.

1 Like

Seems like a trade off situation to me. Have the regressions been pretty major or something that an update of a couple gems solved?

Thanks for your feedback @christoomey

In general the regressions were minor and involved things like renaming a field and not properly updating it in the config file, but some were more subtle and related to complex relationships between models. These become very hard to debug when they originating from deep within meta-programmed gem code.

I’ve used ActiveAdmin quite a bit. It’s really good. When I watched the WI episode on flash cards, where you made a separate interface, I immediately thought it was odd. I would have implemented that right in active admin. It allows you to create admin pages with your own partials and to override the controller. So you are not limited at all. Generally clients use admin interfaces and mine would get confused with two admin areas.

For testing, I have only ever used capybara tests for admin interfaces. Not a common source of bug for me.