Best Practice for Testing Glue/Orchestration Code [closed]
up vote
-2
down vote
favorite
def foo():
data = call_database()
model = marshal(data)
process(model)
foo is some callable that glues together other functions. call_database, marshal, and process must be called serially and do not have shared state. Assume the inner functions have acceptable coverage at the unit level.
What is the best practice for testing glue/orchestration code like foo? This is a simplified example. Imagine there is also exception handling around call_database or maybe a conditional to validate the data before process.
It seems wasteful to test every combination again because that should already be covered by the inner functions' unit tests.
python python-3.x python-2.x unit-testing
asked Nov 26 at 14:51
Duy Nguyen
1
closed as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher Nov 27 at 6:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
-2
down vote
favorite
def foo():
data = call_database()
model = marshal(data)
process(model)
foo is some callable that glues together other functions. call_database, marshal, and process must be called serially and do not have shared state. Assume the inner functions have acceptable coverage at the unit level.
What is the best practice for testing glue/orchestration code like foo? This is a simplified example. Imagine there is also exception handling around call_database or maybe a conditional to validate the data before process.
It seems wasteful to test every combination again because that should already be covered by the inner functions' unit tests.
python python-3.x python-2.x unit-testing
asked Nov 26 at 14:51
Duy Nguyen
1
closed as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher Nov 27 at 6:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher
If this question can be reworded to fit the rules in the help center, please edit the question.
1
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05
add a comment |
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
def foo():
data = call_database()
model = marshal(data)
process(model)
foo is some callable that glues together other functions. call_database, marshal, and process must be called serially and do not have shared state. Assume the inner functions have acceptable coverage at the unit level.
What is the best practice for testing glue/orchestration code like foo? This is a simplified example. Imagine there is also exception handling around call_database or maybe a conditional to validate the data before process.
It seems wasteful to test every combination again because that should already be covered by the inner functions' unit tests.
python python-3.x python-2.x unit-testing
asked Nov 26 at 14:51
Duy Nguyen
1
def foo():
data = call_database()
model = marshal(data)
process(model)
foo is some callable that glues together other functions. call_database, marshal, and process must be called serially and do not have shared state. Assume the inner functions have acceptable coverage at the unit level.
What is the best practice for testing glue/orchestration code like foo? This is a simplified example. Imagine there is also exception handling around call_database or maybe a conditional to validate the data before process.
It seems wasteful to test every combination again because that should already be covered by the inner functions' unit tests.
python python-3.x python-2.x unit-testing
python python-3.x python-2.x unit-testing
asked Nov 26 at 14:51
Duy Nguyen
1
asked Nov 26 at 14:51
Duy Nguyen
1
asked Nov 26 at 14:51
Duy Nguyen
1
asked Nov 26 at 14:51
Duy Nguyen
1
asked Nov 26 at 14:51
Duy Nguyen
1
1
closed as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher Nov 27 at 6:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher
If this question can be reworded to fit the rules in the help center, please edit the question.
closed as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher Nov 27 at 6:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher
If this question can be reworded to fit the rules in the help center, please edit the question.
1
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05
add a comment |
1
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05
1
1
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site. Please take a look at the help center.
– Mast
Nov 26 at 16:05