Best Practice for Testing Glue/Orchestration Code [on hold]
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 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher yesterday
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 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher yesterday
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
2 days ago
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 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
Duy Nguyen
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
Duy Nguyen
1
asked 2 days ago
Duy Nguyen
1
1
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Duy Nguyen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
put on hold as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher yesterday
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.
put on hold as off-topic by Mast, 200_success, Sᴀᴍ Onᴇᴌᴀ, Quill, Heslacher yesterday
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago