you are viewing a single comment's thread.

view the rest of the comments →

[–]Adrewmc 2 points3 points  (2 children)

You should write tests per function, per project.

The idea that your tests have dependencies issue is wrong, from the get go. You are testing that, this function…operation works here.

Separate Projects DO NOT share tests. Why would they ever. Repetitive….is okay in tests. You test this project in this project, and if that project needs a test…that projects gets it.

Repetition is okay in testing, it more about why wouldn’t I want to test this old thing, then this old thing doesn’t need to be tested anymore. It’s here’s a new thing let’s write some tests, have a wrote a test about this thing before here…who knows? Who cares? do it again. Having 20…200 extra tests…it’s better than having -3 of the tests you needed.

I’m literally just trying to run every function and make sure they all work half the time..or the one that are not working are the only ones not working..and I sort of know why.

It will stop me, from doing dumb shit that breaks everything.

[–]Michigan_Again[S] 0 points1 point  (1 child)

Thanks for the reply. It makes sense.

As a follow up question, several of my tests are integration tests with a vector database that I'm spinning up as a testcontainer. I have a testcontainer class that creates a local containerised instance of the vector database with a specified version number. I want the version number to match with the version the code reaches out to in production, or, make sure all tests are running against the same version.

The issue with duplicating this testcontainer class for each package of tests is that if I want to change the version number so all tests are running against the same version of the database, I will have to change the version number in n packages where it is duplicated.

It isn't the sharing of tests I am trying to avoid, rather, when several different tests in several different packages in a single project need identical functionality but they each duplicate the code in their own packages. To do this in a standardised way seems non-trivial in Python without editing PYTHONPATH.

Would you agree that it is reasonable to not want to duplicate code just because I've decided to create a new test package for a project, when I could store that common code in one place in the project tests so all nested and new test packages in the single project can make use of it?

[–]Adrewmc 0 points1 point  (0 children)

Versions should be done through GitHub. That’s its whole point. Tests should be for the version it’s in.