Marking the existing test as @slow and adding the faster test seems
like a good workaround to me.
Aaron Meurer
On Thu, Sep 4, 2014 at 7:12 AM, Sergey B Kirpichev wrote:
> On Thu, Sep 04, 2014 at 08:47:58AM +0200, Joachim Durchholz wrote:
>> Personally, I do not like slow tests. Practice has show
On Thu, Sep 04, 2014 at 08:47:58AM +0200, Joachim Durchholz wrote:
> Personally, I do not like slow tests. Practice has shown that they
> tend to be ignored, and they aren't even always run before a merge.
AFAIK, we check slow tests before merge (at least for reduced
number of versions of the pyth
Am 04.09.2014 um 08:24 schrieb Sergey B Kirpichev:
On Thu, Sep 04, 2014 at 07:54:32AM +0200, Joachim Durchholz wrote:
- Guard against regression. (Normal tests.)
If the SymPy fails
on the same, already reported code sample again (no matter for
which reason) - is that a regression?
Depends on
On Thu, Sep 04, 2014 at 07:54:32AM +0200, Joachim Durchholz wrote:
> - Guard against regression. (Normal tests.)
If the SymPy fails
on the same, already reported code sample again (no matter for
which reason) - is that a regression?
--
You received this message because you are subscribed to the
I think unit tests serve these purposes:
- Document an API by example. (We do that in doctests.)
- Guard against regression. (Normal tests.)
- Test emergent properties, i.e. those that cannot be trivially deduced
from reading the source code. (Doctest or normal test, depending on
whether the
On Wednesday, September 3, 2014 2:07:45 PM UTC-5, Sergey Kirpichev wrote:
>
> On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
>>
>> I think such situations are OK, as long as you understand why the test
>> failed before and verified that the new test really tests the same
Am 03.09.2014 um 21:07 schrieb Sergey Kirpichev:
On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
I think such situations are OK, as long as you understand why the test
failed before and verified that the new test really tests the same
thing.
1. We can make mistakes here
On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote:
>
> I think such situations are OK, as long as you understand why the test
> failed before and verified that the new test really tests the same
> thing.
>
1. We can make mistakes here.
2. Probably, we want to be sure, that we
I think such situations are OK, as long as you understand why the test
failed before and verified that the new test really tests the same
thing.
Aaron Meurer
On Tue, Sep 2, 2014 at 9:26 PM, Chris Smith wrote:
> At https://github.com/sympy/sympy/pull/7945 discussion involving a change
> that I ma
At https://github.com/sympy/sympy/pull/7945 discussion involving a change
that I made to a test that was added in response to issue 6533 has arisen.
In that issue a particular expression (which is slow to compute) raised an
assertion error, identifying that a change needed to be made in the code
10 matches
Mail list logo