Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor testcases to directly use pytest #39

Open
gernot-h opened this issue Aug 21, 2023 · 4 comments · Fixed by #40
Open

refactor testcases to directly use pytest #39

gernot-h opened this issue Aug 21, 2023 · 4 comments · Fixed by #40

Comments

@gernot-h
Copy link
Collaborator

gernot-h commented Aug 21, 2023

We already use pytest, but still derive our test classes from traditional unittest.

This is perfectly valid, but we cannot use some nice pytest features that way. As an example, pytest has built-in support for capturing stdout/stderr, so we could drop our own implementation. I also like pytest's more intuitive assert syntax.

Concrete reason why I ask is that I recently extended our own capture_stdout implementation to support an arbitrary number of arguments and now I noticed that with our own implemenation, I can't capture stdout and check the return value at the same time. All of that would already be available from pytest.

It would however mean a larger rework, but I think it would be possible to migrate file by file where needed.

If you're interested, @tngraf, I could try adding my new tests for #33 in pytest-style or also rewrite the "project createbom" tests in #37 to pytest style.

gernot-h added a commit that referenced this issue Aug 21, 2023
Fixes #39 by adding the necessary infrastructure for pytest-based test
classes and refactoring the "project createbom" testcases to use it.

This shows the pytest assert syntax and how to capture stdout with
pytest using the "capsys" fixture.
@gernot-h
Copy link
Collaborator Author

We now have a first pytest-based class in https://github.com/sw360/capycli/blob/main/tests/test_create_bom.py.

I would however suggest to keep this issue open for a while until at least some more files have been migrated to pytest and/or we added some sentences to https://github.com/sw360/capycli/blob/main/Contributing.md#testing about the future direction.

@gernot-h gernot-h reopened this Sep 11, 2023
@gernot-h
Copy link
Collaborator Author

@tngraf, what do you think, do you want to keep both variants (unittest and pytest-based classes) in the long run, so we can choose case by case or should we strive to migrate all tests to pytest over time?

@tngraf
Copy link
Collaborator

tngraf commented Oct 21, 2023

I did some tests with pytests assert and console output capturing. I agree that these are nice features, but

  • we have many unit tests for capycli that work very well and do not need this functionality
  • you cannot debug unit tests that use pytest's console output capturing ... at least not ina an easy way

I will not block someone from using assert and pytest features, but at the moment I see no reason to rewirte all unit tests.

@gernot-h
Copy link
Collaborator Author

Ok, then let's document it like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants