On 11 Nov 2013 02:12, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
>
> Le 10/11/2013 15:48, Nick Coghlan a écrit :
>
>> It would make more sense to just bake py.test style rich assertions
>> into the language in some way and let people write:
>>
>>      def sum(iterable):
>>          # implementation of sum
>>
>>      assert sum([]) == 0
>>      assert sum([1, 2, 3]) == 6
>
>
> This has the same problem as doctests: it works well for trivial tests like the above, but will be difficult to scale towards more complicated testing.

Yeah, part of my point was actually that module level assertions allow this kind of thing today, and there are good reasons people don't do it in practice.

> unittest-like structuration is really what works best for most testing situations, IMO. Alternative testing schemes for "easier" or "more intuitive" testing have generally failed as general-purpose tools.

Agreed, but the spelling of test assertions as methods on test cases isn't an essential part of that structure. For 3.5, it would be nice to offer either testtools style "matcher" objects or py.test style always-on-in-test-modules rich assertions. Either approach has a real world base to draw from, but would still involve a fair bit of work (they're also not mutually exclusive - a matcher based approach could be used as the back end for rich assertions).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas