It’s the same feeling I have watching people work in Java; their IDE and whole language development experience is a tier above Python. I am surprised that the world decided on Python as the informal lingua franca of science.
The other popular testing library is pytest. So that's more choices than in Java but fewer than in C#.
There are far more unit testing libraries available on the JVM than just JUnit.
Since I've only tried the boring default options, I'd be interested to learn about the more esoteric ones people are using. Could you give examples of some of the permutations of Python test libraries you have run into in practice?
Rest Assured -> Convenience library, not needed for testing APIs in python. Spring Test -> Only needed for the Spring framework. Hamcrest -> No idea wtf this is or why it's needed for unit-testing, but there is a python port: PyHamcrest
The two actual libraries needed for unit-testing are there, fully-featured, and part of the standard library. The other examples you cite are completely irrelevant to normal unit-testing and seem more borne out of the Java ecosystem or your particular methodology for unit-testing web-apis, rather than actually performing a role that can be defined as existing "cross-language". So no, from my observation, there does not appear to be any "mess" in the python unit-testing ecosystem.
However, in general, there are a lot of python libraries out there and they all solve similar problems in different ways. If you go out searching for the "how to do this unit-testing convenience feature" in python you're of course going to find a lot of answers. The same way I found inconclusive results for java when researching this response.
My point is that the Python situation, with two popular choices, is hardly "an eclectic mess". Although strictly speaking it might be true that two choices is twice as eclectically messy as one choice, it's still fewer choices and thus less of a mess than C#'s three choices (and I haven't heard anyone calling that a mess).
The bindings will end up being throw-away code, with https://pybind11.readthedocs.io that's not too bad in terms of time spent.
And since we are speaking about Python integrations, Rust is still at the departure line to anything GPGPU related, even something like .NET has better tooling currently.
Go is a complete joke if it wasn't so sad. Just no.
That's a condition for all TDD.
> I know there's testing frameworks, although it seems more of an eclectic mess than Java
If you look at the test suites for popular libraries like numpy, django, airflow it's mostly `pytest`, `unittest` (part of the standard library), and `nose`.
> where testing and mocking is just a little harder to do...
Mocking is actually pretty easy to do in python using pytest.monkeypatch or unittest.mock. Compared to mocking in a strongly typed language like C++ (and I assume Java) if an object you're mocking implements a particular interface, you would only have to mock out the parts that get exercied by the codepath in the tests you care about.
I was saying, run the program, not run a test in a larger suite.
> > where testing and mocking is just a little harder to do...
You were quoting me trying to say that mocking out system interactions, such as I /O, things with external side-effects, tends to be harder, regardless of Python versus Java.
> Mocking is actually pretty easy to do in python
Let's disagree. As a Java developer, doing some Python takes me a moderate amount of online searching, unless I'm writing the test code, during which the online searching and associated trial and error skyrockets.
Just my modest experience.
A lot of the smartest people are super productive and super considerate of all the possible codepaths when making changes. Bugs still occur due to statically discoverable coding errors.
Just how much harder it is to navigate a new codebase is staggering.
That's because that however good the IDEs are, their language is full of ceremony and stiff-OO abstractions, and Python can achieve in 10 lines what takes Java 100.
Plus it interfaces much better with C/C++/Fortran/etc code, which serious data science libraries are written in.
This makes it much better fit for science than Java. Plus a lot if not most of science code is short scripts and one-off. So the benefits of types for larger projects etc don't come in at all.
Unlike enterprise users, scientists wanting to write a program don't have no time for 100 lines of ceremonial crap to make it look "enterprisy" or have much tolerance for a language with much less expressive power.
Learning a dynamically typed language like Python is moderately easier than learning a statically typed language, especially old-fashioned languages like Java without type inference. OTOH using a statically typed language, once you've learned how to handle it, makes for a more powerful software engineering experience, but you'll have to climb the hill of typing first.
I can appreciate making an investment in tools that make me more productive in the long run, but at some point it has to start paying off. Programming languages have finite useful lifetimes. Common Lisp took me years to learn well, too, but it started paying big dividends after only a couple weeks.