Re: How to break long method name into more than one line?
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 you clearly know what you are testing on. Most of the time, the method name is what you first see when your test fails. Another alternative is to put meaningful string in each of the assert, which is probably not practical. You are right, only people who really follow the TDD method know the good things about it. This naming rule served me very well. Tests method should have meaningful name, and the advice by the book is a meaningful one. I said it's the TDD book because I forgot the exact title. It's actually called Test Driven: TDD and Acceptance TDD for Java Developers. I thought it should be popular enough that most people learned TDD may have heard it also used this naming advice, but look like i was wrong. *The* TDD book? There's only one? Surely not. That rule sounds utterly impractical. I can't think of anything to recommend it. Like any other function, method or class, tests should have meaningful names, but reading the name alone should not necessarily tell you *everything* about the function. We have len, not len_sequence_or_mapping_int, and similarly it is perfectly reasonable to have test_len_empty rather than test_len_emptylist_emptystr_emptyunicode_emptydict_emptyset_emptytuple_zero. I expect that naming rule was invented by either people who have heard of test driven development, but never actually done it, or by people so anally-retentive that if they make seven short car trips over an hour, they check the tyre pressure, oil and water seven times because the manual says to check before *every* trip. No offence. My advice is to moderate the naming convention of your tests with a good dose of common sense and aim for names which are readable rather than names that contain everything including the kitchen sink. Imagine you are in a technical meeting with some of your fellow programmers, and need to ask for help with a failing test. Imagine saying the name of the test aloud in a sentence. Does it add clarity to the discussion, or obfuscate it? People's short term memory can only hold so much (allegedly seven plus or minus two), and if the name itself hits that limit, you leave nothing left for the rest of the sentence. http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two Names should be practically, rather than conforming to some naming rule that hurts readability and obfuscates the tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
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 plus method, with 1 and 1 as the arguments, and expect to return 2. If you use unittest and the right assert method, the message will say more than pass/fail. I believe .AssertEqual(a,b, 'optional message') will say that a is not equal to b, and print the optional message. In addition, if first and second are the exact same type and one of list, tuple, dict, set, frozenset or str or any type that a subclass registers with addTypeEqualityFunc() the type-specific equality function will be called in order to generate a more useful default error message (see also the list of type-specific methods). For instance assertMultiLineEqual(first, second, msg=None) Test that the multiline string first is equal to the string second. When not equal a diff of the two strings highlighting the differences will be included in the error message. This method is used by default when comparing strings with assertEqual(). Sticking this rule also means your test cases are small enough, To me, it makes them too small. I think a test of addition should have multiple input-output pairs. Besides that, a single test output object may need to pass multiple conditions to pass. Putting them all in a single large conjuction would obscure which is not passing. However, anything is better than no tests. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
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
Re: How to break long method name into more than one line?
On Tue, Mar 13, 2012 at 9:30 PM, Jean-Michel Pichavant jeanmic...@sequans.com 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 Russia theme of one-liners. You don't break the laws of physics, they break you. My point is that rules about function names etc are *not* inviolate, and should be treated accordingly. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
On Tue, Mar 13, 2012 at 3:24 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On 12 Mar 2012 00:30:08 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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, or by people so anally-retentive that if they make seven short car trips over an hour, they check the tyre pressure, oil and water seven times because the manual says to check before *every* trip. By which time they find they have to add air, oil, and water as: the pressure gauge usage lets out some air each time; they've wiped a few drops of oil onto a rag each time; and the radiator was still hotpressurized such that they got an overfull result. In defense of such rules: There's a period in every new programmer's life when it helps to learn a whole lot of principles; and if he's working on some collaborative project, rules are the easiest way to demand such behavior. Later on, you learn how and when it's safe to break the rules (and/or how to deal with rule conflicts), but the rules still have value. Just never treat them as laws of physics (in Soviet Physics, rules break you!). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
In article mailman.571.1331492028.3037.python-l...@python.org,
Herman sorsor...@gmail.com 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 found that
def abcdeef\
dddaaa(self):
pass
does not work, but
def \
abcsajfoijfiawifoiwejfoi(self):
pass
works. Is this the only way to do it?
Ahhhg. If you can't fit a test method name into 79
characters, you're doing somthing wrong. Just for fun, I found all the
test methods in the project I'm working on and sorted them by length.
Here's the top of the list:
$ find . -name 'test*py' | xargs grep -h 'def *test' | sort | uniq |
awk '{print length($0), $0}' | sort -nr
55 def test_update_name_changes_dasherized_name(self):
51 def test_get_followers_with_no_followers(self):
50 def test_update_station_song_adds_false(self):
50 def test_anonymous_get_user_collections(self):
49 def test_wrong_user_update_should_fail(self):
49 def test_login_with_email_and_password(self):
47 def test_unknown_station_returns_404(self):
47 def test_login_failure_with_facebook(self):
47 def test_get_follows_with_no_follows(self):
46 def test_station_by_dasherized_name(self):
46 def test_nonexistent_recent_station(self):
46 def test_new_user_with_display_name(self):
46 def test_auto_connect_with_facebook(self):
46 def test_anonymous_created_stations(self):
45 def test_no_php_fatal_error_in_log(self):
45 def test_get_only_songza_followers(self):
45 def test_anonymous_vote_transition(self):
44 def test_non_ascii_global_station(self):
44 def test_global_station_not_found(self):
44 def test_gallery_create_duplicate(self):
44 def test_anonymous_listen_history(self):
and so on down to the wonderfully terse:
21 def test_x(self):
which I'm assuming actually makes sense in the context of the TestCase
class it belongs to. At least I hope it does :-)
The examples above are a reasonable upper limit on the verbosity you
should be shooting for, IMHO.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
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 impractical. I can't think of anything to recommend it. Like any other function, method or class, tests should have meaningful names, but reading the name alone should not necessarily tell you *everything* about the function. We have len, not len_sequence_or_mapping_int, and similarly it is perfectly reasonable to have test_len_empty rather than test_len_emptylist_emptystr_emptyunicode_emptydict_emptyset_emptytuple_zero. I expect that naming rule was invented by either people who have heard of test driven development, but never actually done it, or by people so anally-retentive that if they make seven short car trips over an hour, they check the tyre pressure, oil and water seven times because the manual says to check before *every* trip. No offence. My advice is to moderate the naming convention of your tests with a good dose of common sense and aim for names which are readable rather than names that contain everything including the kitchen sink. Imagine you are in a technical meeting with some of your fellow programmers, and need to ask for help with a failing test. Imagine saying the name of the test aloud in a sentence. Does it add clarity to the discussion, or obfuscate it? People's short term memory can only hold so much (allegedly seven plus or minus two), and if the name itself hits that limit, you leave nothing left for the rest of the sentence. http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two Names should be practically, rather than conforming to some naming rule that hurts readability and obfuscates the tests. It takes up a lot of space and my company has a rule of limiting 79 characters (or 80) per line. I found that def abcdeef\ dddaaa(self): pass does not work, but def \ abcsajfoijfiawifoiwejfoi(self): pass works. Is this the only way to do it? Yes. You can't split tokens over multiple lines, or put any whitespace between them. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to break long method name into more than one line?
In article 4f5d4390$0$29891$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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',
'very',
'long',
'list',
'of',
'token',
'fragments')
def x(self):
blah, blah, blah
which creates a test_some_very_long_list_of_token_fragments method.
But it would be a lot easier to just use sane method names.
--
http://mail.python.org/mailman/listinfo/python-list
