> 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 refinement
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
http://www.numpy.org/devdocs/reference/testing.ht
> 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
that,
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 reaso
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 tes
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):
>
>
> I
+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
BTW:
with pytest.raises(AnException):
Is another nice feature.
-CHB
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
> 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 really
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 functions.
> 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 be
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 ea
13 matches
Mail list logo