On 3/14/2012 4:53 PM, Herman wrote:
I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):
Suppose you want to test that a function call returns a particular
300-char multiline string?
If this test fails, you immediately know that it's testing the
I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):
If this test fails, you immediately know that it's testing the "plus"
method, with 1 and 1 as the arguments, and expect to return 2.
Sticking this rule also means your test cases are small enough, so
On Tue, Mar 13, 2012 at 9:30 PM, Jean-Michel Pichavant
wrote:
> Chris Angelico wrote:
>>
>> Just never treat them as laws of physics (in
>> Soviet Physics, rules break you!).
>
> hum ...
> I wonder how this political message is relevant to the OP problem.
Ehh, it's a reference to the "in Soviet R
Chris Angelico wrote:
Just never treat them as laws of physics (in
Soviet Physics, rules break you!).
ChrisA
hum ...
I wonder how this political message is relevant to the OP problem.
JM
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Mar 13, 2012 at 3:24 AM, Dennis Lee Bieber
wrote:
> On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano
> declaimed the following in
> gmane.comp.python.general:
>> I expect that naming rule was invented by either people who have heard of
>> test driven development, but never actually done it, o
In article <4f5d4390$0$29891$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> You can't split tokens over multiple lines, or put any whitespace
> between them.
Well, if you truly wanted to be perverse, you could write some kind of
decorator:
@make_long_named_test_method('some',
On Sun, 11 Mar 2012 11:53:45 -0700, Herman wrote:
> I am trying to stick to the rule described in the TDD book that, each
> test method name consists of the method name to be tested, inputs and
> the expected outputs.
*The* TDD book? There's only one? Surely not.
That rule sounds utterly impract
In article ,
Herman wrote:
> I am trying to stick to the rule described in the TDD book that, each
> test method name consists of the method name to be tested, inputs and
> the expected outputs. It takes up a lot of space and my company has a
> rule of limiting 79 characters (or 80) per line. I
