Add automated tests to verify functionality about django-dump-die HOT 3 OPEN

Tests have been revamped. At the moment, not all possible output has tests. Easiest way to test is to verify dd display of the provided example views.

Because of how this package works, testing rework was created to be as thorough and technical as possible. Which ended up being very time-consuming to write. They are not done, but in a much better state.

Major notable pending work:

• Datetime values are currently wonky. Tests were written, and all working at one point. But some of them have been temporarily commented out, due to inconsistently failing.
  • Furthermore, some date values use the FreezeGun date mocking, which then means we're technically testing for the FakeDate object, instead of the literal, standard date object. Due to the nature of this package, it seems we should find a way to test literal, standard Date objects.
  • Related to above, but FakeDate's "min"/"max" attributes seem to output differently than standard Date attributes. So those are technically commented out as well.
• Not all listed "complex" types are being tested. The initial ones are, but the very-nested ones do not yet have tests. This is for no reason other than I only have so much time, and felt that testing the initial complex types was "good enough" for this first push. Long-term, we probably do want to test the nested complex types as well.
• Class objects do not yet have any tests. Did not have time to get to it.
• Similarly, the "edge case" page also does not have tests yet.

from django-dump-die.

As of adding t he QueryDict handling function just now, I have created a "Django Request-Response-Cycle Page". I have attempted to create UnitTests, but ran into major issues with mocking uniques. Issues that, frankly, I don't know how to resolve at the current point. See TODO note in test file, above QueryDict test.

Similarly, maybe I overlooked it, but we don't seem to have any tests yet for a standard, minimalistic dictionary? Probably should be in the "complex type" tests. Preferably before the next version change push, so we can have UnitTests that verify my QueryDict updates did not break "general dictionary handling" (I'm fairly confident it didn't, but UnitTests to verify long-term would be nice).

from django-dump-die.

The above noted TODO was:

Due to the number of "unique" values being generated in a Request object, it seems to error out with these tests. Either we get a StopIteration error, due to an insufficient mock range, or we get a RecursionError due to too many calls when we raise this mock value.

After thinking about it, the best solution is probably to create separate views for each test object we need. It's a bit annoying that we need to make a handful of more views just for testing, but I can't currently think of a better another way. And then we can keep the existing page for general user-reference, but just not run tests on it.

(This note and the one directly above (from Aug 7th) are mostly in regards to testing the "ComplexObjects" page. But also applies to any other page we might want to test, which will have many values to display and thus generate a large number of uniques.)

from django-dump-die.