Our development team uses a PEP8 linter which requires a maximum line length of 80 characters.
When I'm writing unit tests in python, I like to have descriptive method names to describe what each test does. However this often leads to me exceeding the character limit.
Here is an example of a function that is too long...
class ClientConnectionTest(unittest.TestCase):
def test_that_client_event_listener_receives_connection_refused_error_without_server(self):
self.given_server_is_offline()
self.given_client_connection()
self.when_client_connection_starts()
self.then_client_receives_connection_refused_error()
You could just write shorter method names!
I know, but I don't want to lose the descriptiveness of the test names.
You could write multi-line comments above each test instead of using long names!
This is a decent idea, but then I won't be able to see the test names when running the tests inside my IDE (PyCharm).
Perhaps you can continue the lines with a backslash (a logical line continuation character).
Unfortunately this isn't an option in Python, as mentioned in Dan's answer.
You could stop linting your tests.
This makes sense in some ways, but it's nice to encourage a well-formatted test suite.
You could increase the line length limit.
Our team likes having the limit because it helps keep the code readable on narrow displays, so this isn't the best option.
You could remove
test
from the start of your methods.
This is not an option. Python's test runner needs all test methods to start with test
or it won't pick them up.
Edit: Some test runners let you specify a regular expression when searching for test functions, although I'd rather not do this because it's extra setup for everyone working on the project.
You could separate the EventListener into its own class and test it separately.
The Event Listener is in its own class (and is tested). It's just an interface that gets triggered by events happening within ClientConnection. This kind of suggestion seems to have good intent, but is misdirected and doesn't help answer the original question.
You could use a BDD Framework like Behave. It's designed for expressive tests.
This is true, and I hope to use more of them in the future. Although I'd still like to know how to split function names across lines.
Is there a way in Python to split a long function declaration across multiple lines?
For example...
def test_that_client_event_listener_receives_
connection_refused_error_without_server(self):
self.given_server_is_offline()
self.given_client_connection()
self.when_client_connection_starts()
self.then_client_receives_connection_refused_error()
Or will I have to bite the bullet and shorten it myself?
This is useful for code readability. To break an expression into multiple lines, wrap the expression around a set of parenthesis and break it down as you want. If the expression is already in a set of parenthesis, square brackets, or curly braces, you can split it to multiple lines.
The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. If necessary, you can add an extra pair of parentheses around an expression, but sometimes using a backslash looks better. Make sure to indent the continued line appropriately.
To break a line in Python, use the parentheses or explicit backslash(/). Using parentheses, you can write over multiple lines. The preferred way of wrapping long lines is using Python's implied line continuation inside parentheses, brackets, and braces.
No, this is not possible.
In most cases such a long name would be undesirable from the standpoint of readability and usability of the function, though your use case for test names seems pretty reasonable.
The lexical rules of Python do not allow a single token (in this case an identifier) to be split across multiple lines. The logical line continuation character (\
at the end of a line) can join multiple physical lines into a single logical line, but cannot join a single token across multiple lines.
You could also write a decorator that mutates .__name__
for the method.
def test_name(name):
def wrapper(f):
f.__name__ = name
return f
return wrapper
Then you could write:
class ClientConnectionTest(unittest.TestCase):
@test_name("test_that_client_event_listener_"
"receives_connection_refused_error_without_server")
def test_client_offline_behavior(self):
self.given_server_is_offline()
self.given_client_connection()
self.when_client_connection_starts()
self.then_client_receives_connection_refused_error()
relying on the fact that Python concatenates source-adjacent string literals.
Per the answer to this question:How to disable a pep8 error in a specific file?, use the # nopep8
or # noqa
trailing comment to disable PEP-8 for a long line. It's important to know when to break the rules. Of course, the Zen of Python would tell you that "Special cases aren't special enough to break the rules."
We can applying decorator to the class instead of method since unittest
get methods name from dir(class)
.
The decorator decorate_method
will go through class methods and rename method's name based on func_mapping
dictionary.
Thought of this after seeing decorator answer from @Sean Vieira , +1 from me
import unittest, inspect
# dictionary map short to long function names
func_mapping = {}
func_mapping['test_client'] = ("test_that_client_event_listener_receives_"
"connection_refused_error_without_server")
# continue added more funtion name mapping to the dict
def decorate_method(func_map, prefix='test_'):
def decorate_class(cls):
for (name, m) in inspect.getmembers(cls, inspect.ismethod):
if name in func_map and name.startswith(prefix):
setattr(cls, func_map.get(name), m) # set func name with new name from mapping dict
delattr(cls, name) # delete the original short name class attribute
return cls
return decorate_class
@decorate_method(func_mapping)
class ClientConnectionTest(unittest.TestCase):
def test_client(self):
# dummy print for testing
print('i am test_client')
# self.given_server_is_offline()
# self.given_client_connection()
# self.when_client_connection_starts()
# self.then_client_receives_connection_refused_error()
test run with unittest
as below did show the full long descriptive function name, thinks it might works for your case though it may not sounds so elegant
and readable from the implementation
>>> unittest.main(verbosity=2)
test_that_client_event_listener_receives_connection_refused_error_without_server (__main__.ClientConnectionTest) ... i am client_test
ok
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With