I am a neat freak.
Shut up, mom!
Ok, when I learn new coding projects, I like to pretend an am super smart and am writing something someone else might care about one day, far from now. In this Python/Django replacement for my personal blog site, I focused on replacing all the core functionality I had with my previous Golang site, but, you know, I was in a hurry and, well, I didn't do any testing.
You shut up too.
Anyway, with my Golang project I forced myself to test everything before I even wrote it.
I promised myself I would catch up on this project so I began to write tests.
My project has pytest-django installed. I also run tests using the standard Django test runner python manage.py test.
Boring so far, I get it. Anyway, I decided, because I'm neat and all, that as I started writing tests for my core website app I didn't like how all of the tests were in the same tests.py file. This file already had tests for my context_processor.py file and I started writing template tests. So, I did as any wise learner should do.
I got organized.
I created a test_cases folder under my website app. Here I added test_* files for any conceivable thing I could ever potentially test. And I separated my testing concerns appropriately. I have achieved clean. I have achieved tidy. I have achieved...wait, what?
$ pytest
==================================================================================================================== test session starts =====================================================================================================================
platform win32 -- Python 3.12.2, pytest-8.1.1, pluggy-1.4.0
django: version: 5.0.4, settings: hamco.settings (from ini)
rootdir: C:\Code\hamco-python\hamco
configfile: pytest.ini
plugins: cov-5.0.0, django-4.8.0, dotenv-0.5.2, mock-3.14.0, xdist-3.5.0
collected 8 items
notes\tests.py .... [ 50%]
website\test_cases\test_templates.py .. [ 75%]
website\test_cases\test_context_processors.py . [ 87%]
website\test_cases\test_views.py . [100%]
===================================================================================================================== 8 passed in 10.78s =====================================================================================================================
Eight tests. 8. You see it? I see it. All good. That's how many I have. Sweet.
Or is it...
$ python manage.py test
Found 6 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
......
----------------------------------------------------------------------
Ran 6 tests in 3.124s
OK
Destroying test database for alias 'default'...
I don't have 6 tests. I have 8. I know. I counted. And Pytest works.
So, running python manage.py test -v 2 to see what it was doing, I discovered it entered my test_cases folder and simply picked one file in the test_cases folder, tested it and called it a day. Someone forgot a for loop me thinks. (And before you ask, yes I have an init.py file in the test_cases folder.
Pytest works, so leave it alone, right?
Nah. Neat freak, remember. Why settle for one when you can have two -- and no, that's not a screed for dating (or is it?) -- cause two is better.
I do as any intelligent person does. Use more intelligent intelligence. Hey, ChatGPT, hook a brother up. What's the dealio here. And I get basically:
"Yeah, dude, finding all the files in a directory is hard for the Django test_runner. Sorry. Maybe use Pytest since it works?"
Undaunted, I go to serious competitor, Gemini and ask the same.
And I get a complete and total answer that IMMEDIATELY disappears into the famous Gemini default position of, before I say too much, pretend I said nothing at all:
"As a language model, I'm not able to assist you with that."
Though it actually put lots of code up, it would immediate erase it and say this. With prodding I did get it to get to the following profound position.
Sticking with Pytest:
If you prefer Pytest's discovery and functionality, using Pytest with pytest-django remains a valid approach. It allows you to leverage Pytest's strengths while still utilizing Django's testing features.
Who am I to argue with things smarter than myself? SHUT UP SISTER.
Ok. Something tells me this seems wrong. I can probably find a third-party discovery test_runner for the Django test suite. I can probably write wicked cool code to do it. But when I already have written pip install pytest-django and it works, why re-invent the wheel? Django test_runner, you are dead to me.