I would love to see the tests that people come up for this...
Tests can be helpful and informative, or they can be make-work boilerplate that will never reveal any flaws. And in this type of code base, it's hard to imagine the test that's written in code that will be informative.
When dealing with data, "testing" is most often done visually, with plotting.
The process of exploratory data analysis is not anything at all like writing code to an architected specification, and the same practices are not as effective for different types of work. Insisting that there should be automated tests for something like this reminds me of the cultural phenomenon of extreme table-phobia in the 2000s that happened as a reaction to using tables for layout. I had trouble getting people to believe that is was OK to use tables for tabular data, it was extremely frustrating. Or in the last 5-10 years, with design trends preferring spare layouts with lots of empty space, it was super hard to get information dense designs into production, because they were so averse to the idea that people may need information density for some things.
I'm also reminded of this video about the deficiencies of notebooks:
https://youtu.be/7jiPeIFXb6U
Yes, there are huge deficiencies to notebooks. But using them is an entirely different task than the type of code that one would write in an IDE, for code that gets put into a library and will be run by others. I have two work modes: 1) IDE (actually Emacs) where I write tests and the code is meant to be reusable, even if it's a one-off script, then 2) exploratory data analysis and processing, in notebooks. Though both of these use code, they do not and should not share much else in the way of practices.
We develop best practices in fields to work against our worst instincts. And once we establish best practices, we become strict about them to make sure we don't fall back into bad practices. But when approaching a different field it's good to reevaluate these best practices to see if they still fit.