-1

As a 30-year software developer, mostly in OO languages, but a newbie at python, I'm looking to find what is best practise for isolating unit tests in python.

Let's say I have the following, semi-pseudo-code. I know some_database_client isn't a real database client:

from some_database_client import connection

connection.connect('server_id', 'username', 'password')

def function_under_test():
    return connection.get_value('some_value_reference') + 10

If I write a test for function_under_test(), then I'm effectively testing the potentially enormous amount of logic in connecting and retrieving the data from connection.

Instead, I really want to test that function_under_test() adds ten to the value retrieved.

This relates to a practical real-world example where the module-level variable connection (or it's real-world equivalent) is referenced heavily all over the code.

Therefore, it would involve a large and therefore very risky change to pass connection as an argument to all the functions that use it. Without doing this though, I can't easily separate the variable connection when I'm trying to unit-test the functions that use it. connection is instantiated before I even get to run the unit-test.

Is there a recommended way to isolate functions like this for testing? I can certainly think of many, many ways, but I suspect that some have more of the "Zen of Python" about them than others. e.g. Wrapping everything in classes is a possibility, but that is perhaps moving too far away from keeping stuff simple, which is a goal of python.

user1738833
  • 101
  • 1
  • 2
  • 3
    You'd [mock the database connection](http://www.voidspace.org.uk/python/mock/). – Martijn Pieters Mar 21 '14 at 16:59
  • 1
    Closely related, possible dupe: [What are good unit tests to cover the use case of rolling a die?](http://programmers.stackexchange.com/q/225523) – Martijn Pieters Mar 21 '14 at 17:00
  • Certainly, I'd want to mock the database connection. Is there a way to do this without having to change any of the code above? – user1738833 Mar 21 '14 at 17:02
  • That's why I linked you to the `mock` library; you'd mock `yourmodule.connection`, which effectively patches your module, temporarily replacing `connection` for the duration of the test. – Martijn Pieters Mar 21 '14 at 17:03
  • Sorry. I've realised that in simplifying for a hypothetical question, the example I've given isn't representative of the code I have. In practice, it's more like this: cnxn = Connection('server_id', ...) def function_under_test(): cnxn.get_value(...) I had already tried to see if the mocks library's "patch" feature could do this, which it can for a function call in a module or class, but I couldn't work out how to replace what is effectively a variable that's already instantiated within the context of the test. e.g. `cnxn` in this example. – user1738833 Mar 21 '14 at 17:10
  • If a) `cnxn` is a global and `Connection()` is executed on import and b) is a local name in your module (`from someplace import Connection`) you'll have to refactor your code a little to allow mocking, but `Connection()` itself can be mocked if `cnxn` is not a global or `Connection()` is still namespaced in your module (in which case you can mock the original module before the module-under-test is imported). – Martijn Pieters Mar 21 '14 at 17:13
  • 2
    But as Rob Y states in [his answer posted below](http://programmers.stackexchange.com/a/233207) you should not use a global for a database connection, don't connect on import! – Martijn Pieters Mar 21 '14 at 17:13
  • lol ...taken from brutal experience. I had to live with a system like that for a year, and couldn't change it because of politics. – sea-rob Mar 21 '14 at 17:42

3 Answers3

1

This relates to a practical real-world example where the module-level variable connection (or it's real-world equivalent) is referenced heavily all over the code. Therefore, while it would involve a large and therefore very risky change to pass connection as an argument to all the functions that use it.

That's the only clean solution. Too late now, but in the future avoid such hidden dependencies if possible. The only other option I can think of is to change the Python path to point to an alternate some_database_client with a stub connection when you run your unit tests.

However...

Instead, I really want to test that function_under_test() adds ten to the value retrieved.

You don't really need to test this. You can prove the correctness of such a trivial function by inspection. Writing unit tests to show it adds ten regardless of whether the return value of connection is 0, positive, negative, odd or even is slower than just looking at it and it still doesn't guarantee correctness. Knowing what not to test is just as important as knowing what to test.

Community
  • 1
Doval
  • 15,347
  • 3
  • 43
  • 58
  • Are you saying that the clean solution is to pass in (or inject) the connection? I would have thought so too, but I'm trying not to bring my pre-conceptions developed in other languages into python if it's inappropriate. I've only been developing python for two weeks. The "+ 10" is only a hypothetical example. I can guarantee I'm not testing anything quite so trivial. – user1738833 Mar 21 '14 at 17:05
  • @user1738833 Yeah, that's what I meant to say. It's almost always a good idea to expose your function's dependencies as arguments if they have some sort of state. Having some secret invisible state affecting the result of a function makes it harder to tell what a program is doing. – Doval Mar 21 '14 at 17:10
1

First, initializing a global connection at the module level is really, really bad practice. Rather, if you have to do that, you should have something like

def connect():
   connection.connect('server_id', 'username', 'password')

if __name__ == '__main__':
   connect()

So that you only actually connect in main execution.

Fortunately, from your code example, even if you connect to the database at the start of the module, you can just ignore that assignment and assign a new mock connection in your test.

def my_test():
   connection = MockConnection()
   function_under_test()
   assert(...)

FWIW I found Python really easy to test because if there's some artifact, dependency, or function that was hard to work with, I'd just shove in an implementation that let me focus on the test.

sea-rob
  • 6,841
  • 1
  • 24
  • 47
  • I thought module level variables were immutable, so I couldn't modify "connection" within the context of the unit test? This is all inherited code. I'm only two weeks into programming python, but I can already see that the test framework in the code I inherited is woeful / non-existent. I'm trying to put one in place without any massive code changes - at least until I get the "Zen of Python" truly embedded in my head. – user1738833 Mar 21 '14 at 17:17
  • lol to quote Guido: "We're all adults here!" The only language I've used that has more flexible binding is Javascript. In Python, you can even add new functions to a module at runtime. The Python mock libraries are really just wrappers around standard tasks like assigning a new function definition to a module. Here's a trick that blew me away; since Python is compile-at-runtime, the source script for *everything* is somewhere on your system in the Python path, so you can just drill in and see exactly what it's doing. – sea-rob Mar 21 '14 at 17:38
  • In java, I feel good if I can push my unit tests above 90%. But in Python, it's really easy to hit 100%, because it's really simple to just drop in mocks for everything hard -- global variables, functions, modules, etc. – sea-rob Mar 21 '14 at 17:41
0

It intrinsically has to do with a basic yet important OOP concept: Inversion of control.

One of the ways to reach it is Dependency Injection. In a few words, instead of calling a determined function specified in the body of the function, you'll call a function given by the caller.

Introducing it to your problem:

def function_under_test(connection):
    return connection.get_value('some_value_reference') + 10

Now, we need to pass an object that has the method get_value. In production, you'd pass the real connection object. When testing, however, you'd pass a mock (fake version) of it.

An example of how easy testing becomes:

class FakeConnection():
    def get_value(self, reference):
        return 30

def test_function():
   connection = FakeConnection()
   result = function_under_test(connection)

   assert result == 40
Enrico P. Varella
  • 101