Connection unit testing in Python

I am new to Python unit testing and I am not sure how i can create a unit test of this function that returns a connection?

def connection(self):

    connection = mysql.connector.connect(host='localhost', 

                     database='test',

                     user='user', 

                     password='password',

                     auth_plugin='mysql_native_password')

    return connection

asked Nov 12 at 3:07

dragonfromdreams

293

What's the point?
– spectras
Nov 12 at 3:10

add a comment |

I am new to Python unit testing and I am not sure how i can create a unit test of this function that returns a connection?

def connection(self):

    connection = mysql.connector.connect(host='localhost', 

                     database='test',

                     user='user', 

                     password='password',

                     auth_plugin='mysql_native_password')

    return connection

asked Nov 12 at 3:07

dragonfromdreams

293

What's the point?
– spectras
Nov 12 at 3:10

add a comment |

I am new to Python unit testing and I am not sure how i can create a unit test of this function that returns a connection?

def connection(self):

    connection = mysql.connector.connect(host='localhost', 

                     database='test',

                     user='user', 

                     password='password',

                     auth_plugin='mysql_native_password')

    return connection

asked Nov 12 at 3:07

dragonfromdreams

293

I am new to Python unit testing and I am not sure how i can create a unit test of this function that returns a connection?

def connection(self):

    connection = mysql.connector.connect(host='localhost', 

                     database='test',

                     user='user', 

                     password='password',

                     auth_plugin='mysql_native_password')

    return connection

python python-unittest mysql-connector-python python-unittest.mock

asked Nov 12 at 3:07

dragonfromdreams

293

asked Nov 12 at 3:07

dragonfromdreams

293

asked Nov 12 at 3:07

dragonfromdreams

293

asked Nov 12 at 3:07

dragonfromdreams

293

asked Nov 12 at 3:07

dragonfromdreams

293

What's the point?
– spectras
Nov 12 at 3:10

add a comment |

What's the point?
– spectras
Nov 12 at 3:10

What's the point?
– spectras
Nov 12 at 3:10

add a comment |

1 Answer
1

active

oldest

votes

You could mock out mysql.connector.connect and ensure that it's called, but honestly this is probably too small a unit to provide any benefits to your unit tests. This is just delegating a call to mysql.connector.connect, which itself should be tested (by the mysql package).

class TestConnection(unittest.TestCase):

    @unittest.mock('module_under_test.mysql.connector.connect')

    def test_connection(self, mockconnect):

        module_under_test.connection()

        mockconnect.assert_called()

I suppose you could also check to make sure that it always returns something (to keep from future revisions forgetting to return out of the function.

    # inside test_connection as above

        connection = module_under_test.connection()

        self.assertIsNotNone(connection)

        mockconnect.assert_called()

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

1

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

1

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53255485%2fconnection-unit-testing-in-python%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

class TestConnection(unittest.TestCase):

    @unittest.mock('module_under_test.mysql.connector.connect')

    def test_connection(self, mockconnect):

        module_under_test.connection()

        mockconnect.assert_called()

I suppose you could also check to make sure that it always returns something (to keep from future revisions forgetting to return out of the function.

    # inside test_connection as above

        connection = module_under_test.connection()

        self.assertIsNotNone(connection)

        mockconnect.assert_called()

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

1

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

1

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

add a comment |

class TestConnection(unittest.TestCase):

    @unittest.mock('module_under_test.mysql.connector.connect')

    def test_connection(self, mockconnect):

        module_under_test.connection()

        mockconnect.assert_called()

I suppose you could also check to make sure that it always returns something (to keep from future revisions forgetting to return out of the function.

    # inside test_connection as above

        connection = module_under_test.connection()

        self.assertIsNotNone(connection)

        mockconnect.assert_called()

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

1

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

1

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

add a comment |

class TestConnection(unittest.TestCase):

    @unittest.mock('module_under_test.mysql.connector.connect')

    def test_connection(self, mockconnect):

        module_under_test.connection()

        mockconnect.assert_called()

I suppose you could also check to make sure that it always returns something (to keep from future revisions forgetting to return out of the function.

    # inside test_connection as above

        connection = module_under_test.connection()

        self.assertIsNotNone(connection)

        mockconnect.assert_called()

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

class TestConnection(unittest.TestCase):

    @unittest.mock('module_under_test.mysql.connector.connect')

    def test_connection(self, mockconnect):

        module_under_test.connection()

        mockconnect.assert_called()

I suppose you could also check to make sure that it always returns something (to keep from future revisions forgetting to return out of the function.

    # inside test_connection as above

        connection = module_under_test.connection()

        self.assertIsNotNone(connection)

        mockconnect.assert_called()

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

edited Nov 12 at 3:29

answered Nov 12 at 3:12

Adam Smith

33.1k53174

answered Nov 12 at 3:12

Adam Smith

33.1k53174

answered Nov 12 at 3:12

Adam Smith

33.1k53174

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

1

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

1

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

add a comment |

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

1

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

1

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

This provides no value whatsoever. What matters given (limited) context is what the function returns, not how it creates it. To me this test is a clear violation of encapsulation. In fact, a function that calls connect then returns 42 will pass that test, while a function that returns a proper connection through another mean will fail it.
– spectras
Nov 12 at 3:31

@spectras I agree and mentioned as much in the answer, though I'm not sure how it's a clear violation of encapsulation.
– Adam Smith
Nov 12 at 3:33

It looks at the inside implementation of connection(). Assuming the point of connection() is to encapsulate the details of creating a connection, encapsulation is broken. To be fair, to make a proper test we should have the documentation of the function. If it says “invoke mysql.connector.connect” then fair enough. But if it just says “create a connection”, that's what should be tested: that it returns a proper connection (isinstance of a specific class, a cursor method can be called on returned object…). How it creates it is irrelevant, unless part of the contract.
– spectras
Nov 12 at 3:40

@spectras that's a fair assessment. Without a better idea of what connection does it's tough to advise further, however :(. if connection took a path to host, it would be easier to mock out (you could mock a sql database with some test data in your setUp, then open a connection to it and do some stuff with the cursor, asserting its results.
– Adam Smith
Nov 12 at 4:57

Agreed, as is, the function is not well defined and lacks instrumentation to be testable in a really useful way.
– spectras
Nov 12 at 11:15

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Ndtyjky