test.py

[jgarte]

Hi,

I noticed that there is no documentation for how to run test.py.

https://github.com/staticshock/colored-traceback.py/blob/master/test.py#L23

When should one run each of the test flags?

Does this file suffice for integration testing the package?

all best

[jgarte]

Oh, is this test.py just meant to fail in order to show the colored traceback working?

[staticshock]

yeah, test.py's whole purpose is to throw an error

[jgarte]

Would you accept a pull request for me to turn that test into a with pytest.raises unittest?

https://docs.pytest.org/en/7.1.x/how-to/assert.html#assertions-about-expected-exceptions

[staticshock]

Well, as structured, test.py is a visual inspection test. You run the test script, it throws an error, and you inspect that the traceback shows up with syntax highlighting. Any attempt to turn that into a unit test would (1) need to test that the result has colors, and not just that an exception was thrown, (2) necessarily require multiple tests.

So, the short answer to your question is "no," unless you can demonstrate that you have a solid grasp of the use cases covered by the existing test, and unless you can produce an alternative that does not significantly bloat the line count to cover those use cases.

[hartwork]

@staticshock my impression is:

• test.py seems to be an end user demo rather than unit tests; my vote for a rename to demo.py
• I did not find any actual unit tests or CI — is there any?
• adding unit tests covering demo.py would not be hard but sure increase line count. with patch("sys.stderr", StringIO()) would be the key piece to redirect and inspect output written to standard error, all else is glue.

[staticshock]

New development on this project should target tangible improvements for prospective users, such as fixing issues experienced by users or adding features that would benefit them. Unless internally-motivated projects such as testing are anchored to user-facing goals, we have no real way of assessing their value.

A common reason for investing in a test suite is to prevent regressions in the course of ongoing development. To that end, adding a way to check that this package works for all python versions that haven't been EOL'ed yet (currently that's all versions between 3.8 and 3.14) could be useful.

[hartwork]

A common reason for investing in a test suite is to prevent regressions in the course of ongoing development.

Exactly.