search

SebKuzminsky / pycam

Other
342 stars 101 forks source link

0.6 pytest #83

Closed SebKuzminsky closed 7 years ago

SebKuzminsky commented 7 years ago

This PR removes the old bit-rotted manual tests and starts adding new automatic tests using pytest. Run the tests with "make pytest" (which is also included in "make test").

Thanks to @zancas for help with python and the pytest framework.

zancas commented 7 years ago

@SebKuzminsky Are these pytest results consistent with yours?

pytestresults
zancas commented 7 years ago

I vote we do not alter the Makefile at all. Instead, I think we should alter .travis.yml to run: py.test .

I am not yet sure what to do about the test_intersection.py failures, are they new?

I'm not very sure about removing the Make target, I'd like to discuss pros-and-cons before we act on that idea.

So, I guess I mean: "I vote we discuss removing the 'test' directive from the Makefile."

SebKuzminsky commented 7 years ago

Oops, i missed the pycam/Tests directory. I'll move the Polygon tests there. And I'll change the name to begin with "test_" for consistency with the existing tests, and to make pytest happy. And that lets me simplify the Makefile test target...

SebKuzminsky commented 7 years ago

The intersection tests have never passed. They failed when they were first committed to the "test" branch on SourceForge back in 2013 and they failed when the "test" branch was merged into master in February 2017. I'm going to disable them.

SebKuzminsky commented 7 years ago

Grumble, on Debian 9 (Stretch, aka stable), python-pytest supplies /usr/bin/pytest, but on Ubuntu 14.04 (Trusty, where our Travis instance runs) it does not. On Trusty it provides /usr/bin/py.test, but it doesn't understand the skip directives for the failing tests.

SebKuzminsky commented 7 years ago

@zancas I chose to update the "make test" target to run pytest (in addition to the flake check it was running before) because I like being abe to run all of a project's tests with a single unchanging command. I think "make test" is a fairly common way to do this. It's nice because it's independent of implementation details like whether it's using pytest or something else (or multiple test frameworks).

What's the argument against having a "make test" target?

SebKuzminsky commented 7 years ago

All the issues that @zancas identified have been addressed, but all the iterating has left the history of this branch messy. I've cleaned up the history in a new branch called 0.6-pytest-2, and opened PR #85 to merge it into stable/0.6. I'm closing this PR.