[malkia]

I'm just amazed the lengths people go to complicate debugging (two runtimes), building (two things) and deploying (not single executable). Okay, maybe it's worth it for something (e.g. real "C" code used in Python, but just for the sake of testing... hmmm... no)

[Too]

Depending on the size of your program, investing in test is something that shouldn’t be underrated. For big projects never call it “just” testing.

This example can be useful to generate rich test-data. Imagine you have some C program parsing json. Generating a sample json input in C would be very long and error prone, whereas in python it’s just a few loops for the generation and finally json.dumps.

This also decouples your test from your program, so you don’t do the same mistake in both of them, negating the test.

In same manner, parameterizing tests is surely possibly with GTest but it’s awkward and complicated, a lot easier in py.

Pytest also comes with lots of fixtures and possibility to make your own, such as spinning up a mock-db, although then we are more into integration testing rather than unit.

Not saying everyone should go rewrite their tests like this, but for some cases there is value that can be utilized.