Use pytest

[pefoley2]

setup.py test is deprecated, switch to pytest.

[etnguyen03]

Apologies if I'm being naive but could we just use and call ./manage.py test?

E: Never mind

[pefoley2]

Sure, but it's IMO a nicer experience.
e.g. you actually get warnings called out.
There's also https://pytest-django.readthedocs.io/en/latest/index.html#why-would-i-use-this-instead-of-django-s-manage-py-test-command

[pefoley2]

If you look at https://github.com/tjcsl/ion/pull/1143/checks?check_run_id=2703066197, you can see the 21 previously failing tests that weren't being run for whatever reason.

[Laur04]

Interesting, I can't replicate these failures using pytest or python manage.py test locally using either the current dev or this branch. Do you have an Ion dev env where you are seeing all of these failures locally or is it just in running CI? Both the current method of running tests and pytest both report running 285 tests...I might have a theory, but I'd have to look more. @etnguyen03 can you replicate?

[pefoley2]

I can repo locally by running pytest in my ion venv.
I can't repo w/ ./manage.py test though.
I suspect that manage.py isn't as comprehensive wrt test discovery compared to pytest so it's simply missing some that don't match its expected naming, although I haven't actually confirmed that one way or the other.

[Laur04]

Both ./manage.py test and pytest are running 285 tests though.

[pefoley2]

Oh...
I see what's going on.
./manage.py test and ./setup.py test match this condition:
https://github.com/tjcsl/ion/blob/master/intranet/settings/__init__.py#L74

Which forces them to use sqlite3, which makes stuff pass that doesn't w/ postgres (like the column length assertions).
adding and False to that if gives:
Traceback (most recent call last):
File "/home/peter/ion/intranet/apps/eighth/tests/test_profile.py", line 155, in test_profile_signup_view
self.assertEqual(scheduled.id, response.context["active_block_current_signup"])
AssertionError: 703 != 706

So it's not so much an issue with ./manage.py test as an issue w/ sqlite.

Given the apparently not great compatibility w/ sqlite, I'd consider switching the ci to use postgres.
Or just using --keepdb, which gives:
real 0m9.249s
for postgres, and:
real 0m9.190s
for sqlite...

[Laur04]

you've got some weird branch conflicts going on here...targeting dev should fix that

[Laur04]

This is going to be a fairly extensive PR to fix all of the issues that aren't being caught with the current sqlite database. We also want to be able to run these tests locally, which is going to involve removing the in memory testing altogether since that isn't compatible with postgres. Do you want to (1) leave this PR at just switching CI to pytest and the fixes you made to a few tests and I'll merge it and deal with patching everything else and switching local testing, (2) add onto this, patching everything and switching to postgres for local testing or (3) something else?

[pefoley2]

Yeah, I think I'll just focus this pr on the pytest switch and leave sqlite->postgres to #1144.
I rebased it on latest dev and fixed a bunch more warnings, PTAL

[coveralls]

Coverage decreased (-0.1%) to 82.408% when pulling 9b2c390 on pefoley2:master into 711ac75 on tjcsl:dev.

[Laur04]

LGTM