Hacker News Reader

> The condition is, though, that I need to be able to quickly run the program to validate just all of it to work.

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.

> That's a condition for all TDD.

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.

The problem is small and medium programs have a tendency to metastasize into large ones.

There's a controlled way of doing that. Prototype in python, as soon as it's clear what/how things need to be done, implement in C++, add python bindings for manual testing, unit-tests to solidify things.

The bindings will end up being throw-away code, with https://pybind11.readthedocs.io that's not too bad in terms of time spent.

Hopefully you would implement new, greenfield projects in Rust or perhaps Go, not C++. There's also a side-benefit in that Rust interoperates more easily with Python and similar languages, due to its features being a closer match to the C ABI.

Rust still needs to do a lot to catch up with 30 years of tooling and libraries.

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.

A modern C++ is head and shoulders above Rust. Rust might get there in a decade or two; not today.

Go is a complete joke if it wasn't so sad. Just no.

Sure, but isn't any code hygiene a matter of discipline, in this case switching over before it gets out of hand? The only reason my small programs are in Python and not in BASH is because of the same discipline. Also, being in a post-monolith era I hope this is all less of an issue.

In my opinion, there is always a lot of pressure that keeps people from maintaining good discipline, so there's a lot of value in tying your hands up-front in a way that ensures a bare minimum of maintainability.

Python has the unittest module, which is a port of JUnit, in the standard library. (And a mocking library as well.)

The other popular testing library is pytest. So that's more choices than in Java but fewer than in C#.

> 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.

Yes, I meant "more choices that are popular" - of those libraries JUnit is the obvious default choice that most people use, unlike in C# where you have NUnit, xUnit and MSTest all enjoying comparable popularity (to each other).

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).

For the combination of JUnit, Mockito, Hamcrest, Rest Assured and Spring Test (each of which playing its own role in testing) I am able to more-reliably find answers than for the combinations of Python libraries that I seem to run into. They may be less in absolute numbers, but if (my perception) they appear in too many permutations, it's often hard to find the right answers.

JUnit -> unittest (std lib) Mockito -> mock (std lib)

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.

An equivalent to Spring Test + JUnit in Python might be Django's testing framework, which extends the standard library's unittest module. REST Assured might not need an equivalent - the documentation says it "brings the simplicity of using [dynamic languages such as Ruby and Groovy] into the Java domain". As for Hamcrest, I don't know what you would use with unittest (other than the build-in assertions), but I think pytest does some clever introspection to give similar results when it comes to error reporting.

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?