I'm rather impartial about having slow tests or not. I don't mind if a
test runs two days ... well okay, it want the suite to finish within a
night's sleep so I can upload the prepared pull request on the next day
without having to worry too much about intermediate pull requests, but
that's about it.
What I do care about is tests that fail because nobody ran them before
uploading a pull request.
Or tests that are known to fail, but didn't get an @XFail for whatever
reason.
My problem is that I see a gazillion of stack traces in my test log, and
I don't know which of them I need to clean up.
I shouldn't have to worry about that. Tests known to fail should have
been marked @XFaile before the pull request got merged.
And if a test isn't run before the merge, then it shouldn't be part of
the automatic test suite.
See, I hate submitting stuff that breaks things. Partly because I hate
to make the lives of other people miserable, partly because I hate going
back to work that's supposed to be finished.
This test failure situation increases the chances I'm submitting broken
stuff. I'm working on C, which is used almost everywhere, so I have a
larger than normal chance of breaking everybody's daily usage, so I need
to extra super careful. That's why I'm so incredibly nitpicky about this.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
