Wrote a mock convertor and checked it wasn't called. Wondering if it'd be useful to have a unit registry context manager, but that's very very outside the scope of this PR. (ETA: also a dummy units fixture)

I'm not following the purpose of this PR. It would be like testing that set_xlabel or the string argument of ax.text doesn't participate in the units pipeline. It is hard to understand how anyone could ever screw that up to justify the extra complexity and compute time.

It is hard to understand how anyone could ever screw that up to justify the extra complexity and compute time.

It's a unit test that takesalmost no time .9 second at most to run, and the complexity is the most straightforward unit + conversion you can write.

Yes, it's testing that table does what we expect it to so that it someone refractors table (which is a thing lots of folks have wanted to do) we have a test that it still behaves as expected. Also depending on where units go, it may make sense for table to participate in units...

I'm all for dumb tests that verify things do exactly what we say they do given the amount of side quests involved in making almost any medium sized change.

It would be like testing that set_xlabel or the string argument of ax.text doesn't participate in the units pipeline.

ax.text takes numbers for the positions so arguably it should (and maybe does?) participate in the units pipeline.

I'm also slightly confused as to what this is testing? Are you trying to check that e.g., a datetime in a table doesn't get converted by the units machinery to a floating point number before being converted to a string to go in the table?

Are you trying to check that e.g., a datetime in a table doesn't get converted by the units machinery to a floating point number before being converted to a string to go in the table?

Basically. Since table is doing an internal conversion using string, just double checking that that's what it's doing. This is a "this is our underlying assumption" test.