A better way to organize my test functions
up vote
-2
down vote
favorite
I'm writing a software application of a few thousand lines of code (in Python), and in order to keep the whole thing together, slowly but certainly the need for unit tests (and later, other types of tests...) has arisen.
My problem is how to organize the many testing functions that I've written so far: Suppose I have a function myfunc for which I want to write tests. What I have are functions like so:
test1pos_myfunc():
#...
test2pos_myfunc():
#...
test3pos_myfunc():
#...
#and so on...
that each test whether one input if myfunc delivers the correct output. Then I also have another suite of functions where I test where the correct exceptions get thrown if I give bad input to myfunc; these are
test1neg_myfunc():
#...
test2neg_myfunc():
#...
test3neg_myfunc():
#...
#and so on...
This setup seems less than ideal, in particular for "negative" tests, because often I group together those functions that test whether the same exception gets thrown - e.g. test1neg_myfunc, test2neg_myfunc and test3neg_myfunc might all test if the same exception MyError gets thrown for different inputs and test4neg_myfunc and test5neg_myfunc might test if the same MyHorribbleError gets thrown.
Now if I want to add one more testing function to test ´MyError` I have to renumber all the other functions. What would be a better way to organize this?
Here are some solutions I thought of, but none satisfy me:
use the name of the exception in the function name and restart numbering for every test of a new exception (seems like a bad idea, because it will reduce readability), e.g.
test1MyError_myfunc,test2MyError_myfuncand so on.take all tests of one exception and lump them as methods in a class; and then also lump all tests belonging to one function in a class (this is better my test names will become shorter and - but then again it feels bad, because I'm importing a concept from OOP into a setting where I'm programming strictly procedurally! And using a class just to lump together some functions seems overkill; doesn't Python offer anything better as a container to store other things?)
outsource all the tests, similar to the organization in classes, in different modules (everything I wrote about classes applies, but with the huge disadvantage that I will have a ton of files then laying around)
Can anybody come up with something better? What are industry standards here? (I'm a novice programmer.)
python unit-testing
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
-2
down vote
favorite
I'm writing a software application of a few thousand lines of code (in Python), and in order to keep the whole thing together, slowly but certainly the need for unit tests (and later, other types of tests...) has arisen.
My problem is how to organize the many testing functions that I've written so far: Suppose I have a function myfunc for which I want to write tests. What I have are functions like so:
test1pos_myfunc():
#...
test2pos_myfunc():
#...
test3pos_myfunc():
#...
#and so on...
that each test whether one input if myfunc delivers the correct output. Then I also have another suite of functions where I test where the correct exceptions get thrown if I give bad input to myfunc; these are
test1neg_myfunc():
#...
test2neg_myfunc():
#...
test3neg_myfunc():
#...
#and so on...
This setup seems less than ideal, in particular for "negative" tests, because often I group together those functions that test whether the same exception gets thrown - e.g. test1neg_myfunc, test2neg_myfunc and test3neg_myfunc might all test if the same exception MyError gets thrown for different inputs and test4neg_myfunc and test5neg_myfunc might test if the same MyHorribbleError gets thrown.
Now if I want to add one more testing function to test ´MyError` I have to renumber all the other functions. What would be a better way to organize this?
Here are some solutions I thought of, but none satisfy me:
use the name of the exception in the function name and restart numbering for every test of a new exception (seems like a bad idea, because it will reduce readability), e.g.
test1MyError_myfunc,test2MyError_myfuncand so on.take all tests of one exception and lump them as methods in a class; and then also lump all tests belonging to one function in a class (this is better my test names will become shorter and - but then again it feels bad, because I'm importing a concept from OOP into a setting where I'm programming strictly procedurally! And using a class just to lump together some functions seems overkill; doesn't Python offer anything better as a container to store other things?)
outsource all the tests, similar to the organization in classes, in different modules (everything I wrote about classes applies, but with the huge disadvantage that I will have a ton of files then laying around)
Can anybody come up with something better? What are industry standards here? (I'm a novice programmer.)
python unit-testing
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
I'm writing a software application of a few thousand lines of code (in Python), and in order to keep the whole thing together, slowly but certainly the need for unit tests (and later, other types of tests...) has arisen.
My problem is how to organize the many testing functions that I've written so far: Suppose I have a function myfunc for which I want to write tests. What I have are functions like so:
test1pos_myfunc():
#...
test2pos_myfunc():
#...
test3pos_myfunc():
#...
#and so on...
that each test whether one input if myfunc delivers the correct output. Then I also have another suite of functions where I test where the correct exceptions get thrown if I give bad input to myfunc; these are
test1neg_myfunc():
#...
test2neg_myfunc():
#...
test3neg_myfunc():
#...
#and so on...
This setup seems less than ideal, in particular for "negative" tests, because often I group together those functions that test whether the same exception gets thrown - e.g. test1neg_myfunc, test2neg_myfunc and test3neg_myfunc might all test if the same exception MyError gets thrown for different inputs and test4neg_myfunc and test5neg_myfunc might test if the same MyHorribbleError gets thrown.
Now if I want to add one more testing function to test ´MyError` I have to renumber all the other functions. What would be a better way to organize this?
Here are some solutions I thought of, but none satisfy me:
use the name of the exception in the function name and restart numbering for every test of a new exception (seems like a bad idea, because it will reduce readability), e.g.
test1MyError_myfunc,test2MyError_myfuncand so on.take all tests of one exception and lump them as methods in a class; and then also lump all tests belonging to one function in a class (this is better my test names will become shorter and - but then again it feels bad, because I'm importing a concept from OOP into a setting where I'm programming strictly procedurally! And using a class just to lump together some functions seems overkill; doesn't Python offer anything better as a container to store other things?)
outsource all the tests, similar to the organization in classes, in different modules (everything I wrote about classes applies, but with the huge disadvantage that I will have a ton of files then laying around)
Can anybody come up with something better? What are industry standards here? (I'm a novice programmer.)
python unit-testing
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I'm writing a software application of a few thousand lines of code (in Python), and in order to keep the whole thing together, slowly but certainly the need for unit tests (and later, other types of tests...) has arisen.
My problem is how to organize the many testing functions that I've written so far: Suppose I have a function myfunc for which I want to write tests. What I have are functions like so:
test1pos_myfunc():
#...
test2pos_myfunc():
#...
test3pos_myfunc():
#...
#and so on...
that each test whether one input if myfunc delivers the correct output. Then I also have another suite of functions where I test where the correct exceptions get thrown if I give bad input to myfunc; these are
test1neg_myfunc():
#...
test2neg_myfunc():
#...
test3neg_myfunc():
#...
#and so on...
This setup seems less than ideal, in particular for "negative" tests, because often I group together those functions that test whether the same exception gets thrown - e.g. test1neg_myfunc, test2neg_myfunc and test3neg_myfunc might all test if the same exception MyError gets thrown for different inputs and test4neg_myfunc and test5neg_myfunc might test if the same MyHorribbleError gets thrown.
Now if I want to add one more testing function to test ´MyError` I have to renumber all the other functions. What would be a better way to organize this?
Here are some solutions I thought of, but none satisfy me:
use the name of the exception in the function name and restart numbering for every test of a new exception (seems like a bad idea, because it will reduce readability), e.g.
test1MyError_myfunc,test2MyError_myfuncand so on.take all tests of one exception and lump them as methods in a class; and then also lump all tests belonging to one function in a class (this is better my test names will become shorter and - but then again it feels bad, because I'm importing a concept from OOP into a setting where I'm programming strictly procedurally! And using a class just to lump together some functions seems overkill; doesn't Python offer anything better as a container to store other things?)
outsource all the tests, similar to the organization in classes, in different modules (everything I wrote about classes applies, but with the huge disadvantage that I will have a ton of files then laying around)
Can anybody come up with something better? What are industry standards here? (I'm a novice programmer.)
python unit-testing
python unit-testing
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
l7ll7
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
l7ll7
97
asked 1 hour ago
l7ll7
97
97
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
l7ll7 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
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: "196"
};
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',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
l7ll7 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209731%2fa-better-way-to-organize-my-test-functions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
l7ll7 is a new contributor. Be nice, and check out our Code of Conduct.
l7ll7 is a new contributor. Be nice, and check out our Code of Conduct.
l7ll7 is a new contributor. Be nice, and check out our Code of Conduct.
l7ll7 is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- 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.
Use MathJax to format equations. MathJax reference.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209731%2fa-better-way-to-organize-my-test-functions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
