> On Aug 8, 2018, at 5:40 PM, Matti Picus wrote:
> We have these guidelines http://www.numpy.org/devdocs/reference/testing.html,
Thanks Matti — that’s clearly the place to document best practices.
> It was updated for pytest in the 1.15 release, but could use some more
> editing and
On 08/08/18 17:34, Juan Nunez-Iglesias wrote:
A NumPy document on preferred testing practices would be very valuable
even to projects beyond NumPy, just like HOW_TO_DOCUMENT.txt was
valuable to the entire ecosystem.
We have these guidelines
> I find the way that pytest automatically match *argument names* with
> the names of fixtures very distasteful and un-Pythonic.
THIS! I've been wanting to articulate this for a while but couldn't
quite put my finger on it.
Nevertheless, I agree with the sentiment in this thread, specifically
On Wed, Aug 8, 2018 at 9:25 AM Tyler Reddy wrote:
> +1 for pytest parametrization and some of the more straight forward
> context managers like pytest.raises and so on
>
+1 from me, too.
> +0.5 for the fancy fixture stuff in pytest (have to concede that this
> stuff can be really hard to
On Wed, Aug 8, 2018 at 9:38 AM, Evgeni Burovski
wrote:
> Stdlib unittest supports self.assertRaises context manager from python 3.1
>
but that requires using unittest :-)
On Wed, Aug 8, 2018, 7:30 PM Eric Wieser
> wrote:
>
>> You forget that we already have that feature in our testing layer,
This is actually available from both nose (old-style np.testing framework),
and pytest. Stdlib unittest supports self.assertRaises context manager from
python 3.1
On Wed, Aug 8, 2018, 7:30 PM Eric Wieser
wrote:
> Is another nice feature
>
> You forget that we already have that feature in our
Is another nice feature
You forget that we already have that feature in our testing layer,
with np.testing.assert_raises(AnException):
pass
On Wed, 8 Aug 2018 at 09:08 Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> BTW:
>
> with pytest.raises(AnException):
>
>
>
+1 for pytest parametrization and some of the more straight forward context
managers like pytest.raises and so on
+0.5 for the fancy fixture stuff in pytest (have to concede that this stuff
can be really hard to reason about sometimes,
especially with custom scoping decorators, but if it helps to
> as to whether we are should use pytest fixtures and parametrized classes and
> functions.
Absolutely!
> the disadvantage is being dependent on pytest as unittest does not
support that functionality.
Which is the whole point of using pytest, yes?
I’m very opinionated about this, but I
On Wed, Aug 8, 2018 at 8:27 AM, Hameer Abbasi
wrote:
> > On 8. Aug 2018, at 17:23, Charles R Harris
> wrote:
> >
> > Hi All,
> >
> > I'm writing some tests and would like to come to a common understanding
> as to whether we are should use pytest fixtures and parametrized classes
> and
> On 8. Aug 2018, at 17:23, Charles R Harris wrote:
>
> Hi All,
>
> I'm writing some tests and would like to come to a common understanding as to
> whether we are should use pytest fixtures and parametrized classes and
> functions. The immediate problem is testing over all types that should
Hi All,
I'm writing some tests and would like to come to a common understanding as
to whether we are should use pytest fixtures and parametrized classes and
functions. The immediate problem is testing over all types that should be
supported, which something we should to much more of and is most
12 matches
Mail list logo
