Should I write unit tests for child class' inherited behaviour?
Let's say I have a Chart class with setDatasets() method for which I have written unit tests.
class Chart {
// constructor and instance properties
setDatasets() {
// some logic
}
}
Now I have also BarChart class which is Chart's child class:
class BarChart extends Chart {
// just a constructor invoking super() with specific parameters
}
Obviously BarChart instances will "inherit" setDatasets() method from Chart class. My question is: should I also write unit tests for setDatasets() method in BarChart?
javascript unit-testing
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
add a comment |
Let's say I have a Chart class with setDatasets() method for which I have written unit tests.
class Chart {
// constructor and instance properties
setDatasets() {
// some logic
}
}
Now I have also BarChart class which is Chart's child class:
class BarChart extends Chart {
// just a constructor invoking super() with specific parameters
}
Obviously BarChart instances will "inherit" setDatasets() method from Chart class. My question is: should I also write unit tests for setDatasets() method in BarChart?
javascript unit-testing
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
Is there a reason for not to do it? What would happen ifBarChartimplements a differentsetDatasets()in the future? I'm not an expert on test development but I guess the more you test, the better.
– fsinisi90
Nov 22 '18 at 19:37
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
1
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45
add a comment |
Let's say I have a Chart class with setDatasets() method for which I have written unit tests.
class Chart {
// constructor and instance properties
setDatasets() {
// some logic
}
}
Now I have also BarChart class which is Chart's child class:
class BarChart extends Chart {
// just a constructor invoking super() with specific parameters
}
Obviously BarChart instances will "inherit" setDatasets() method from Chart class. My question is: should I also write unit tests for setDatasets() method in BarChart?
javascript unit-testing
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
Let's say I have a Chart class with setDatasets() method for which I have written unit tests.
class Chart {
// constructor and instance properties
setDatasets() {
// some logic
}
}
Now I have also BarChart class which is Chart's child class:
class BarChart extends Chart {
// just a constructor invoking super() with specific parameters
}
Obviously BarChart instances will "inherit" setDatasets() method from Chart class. My question is: should I also write unit tests for setDatasets() method in BarChart?
javascript unit-testing
javascript unit-testing
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
asked Nov 22 '18 at 19:28
rufus1530rufus1530
411211
411211
Is there a reason for not to do it? What would happen ifBarChartimplements a differentsetDatasets()in the future? I'm not an expert on test development but I guess the more you test, the better.
– fsinisi90
Nov 22 '18 at 19:37
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
1
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45
add a comment |
Is there a reason for not to do it? What would happen ifBarChartimplements a differentsetDatasets()in the future? I'm not an expert on test development but I guess the more you test, the better.
– fsinisi90
Nov 22 '18 at 19:37
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
1
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45
Is there a reason for not to do it? What would happen if
BarChart implements a different setDatasets() in the future? I'm not an expert on test development but I guess the more you test, the better.– fsinisi90
Nov 22 '18 at 19:37
Is there a reason for not to do it? What would happen if
BarChart implements a different setDatasets() in the future? I'm not an expert on test development but I guess the more you test, the better.– fsinisi90
Nov 22 '18 at 19:37
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
1
1
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45
add a comment |
1 Answer
1
active
oldest
votes
No that would be overkill. A Test class for BarChart is supposed to test only the code introduced in BarChart.
In your case, you should only test that the BarChart object is created with the "specific parameters".
Last but not least, on the long run, it will be easier to maintain if your unit tests are isolated and precise.
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
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
});
}
});
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%2fstackoverflow.com%2fquestions%2f53437090%2fshould-i-write-unit-tests-for-child-class-inherited-behaviour%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
No that would be overkill. A Test class for BarChart is supposed to test only the code introduced in BarChart.
In your case, you should only test that the BarChart object is created with the "specific parameters".
Last but not least, on the long run, it will be easier to maintain if your unit tests are isolated and precise.
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
add a comment |
No that would be overkill. A Test class for BarChart is supposed to test only the code introduced in BarChart.
In your case, you should only test that the BarChart object is created with the "specific parameters".
Last but not least, on the long run, it will be easier to maintain if your unit tests are isolated and precise.
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
add a comment |
No that would be overkill. A Test class for BarChart is supposed to test only the code introduced in BarChart.
In your case, you should only test that the BarChart object is created with the "specific parameters".
Last but not least, on the long run, it will be easier to maintain if your unit tests are isolated and precise.
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
No that would be overkill. A Test class for BarChart is supposed to test only the code introduced in BarChart.
In your case, you should only test that the BarChart object is created with the "specific parameters".
Last but not least, on the long run, it will be easier to maintain if your unit tests are isolated and precise.
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
edited Nov 23 '18 at 1:41
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
answered Nov 22 '18 at 19:45
VirtualTrollVirtualTroll
2,44712238
2,44712238
add a comment |
add a comment |
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.
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%2fstackoverflow.com%2fquestions%2f53437090%2fshould-i-write-unit-tests-for-child-class-inherited-behaviour%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
Is there a reason for not to do it? What would happen if
BarChartimplements a differentsetDatasets()in the future? I'm not an expert on test development but I guess the more you test, the better.– fsinisi90
Nov 22 '18 at 19:37
I'm, worried about code duplication - I would have exactly the same test code in multiple places. I could abstract this to a separate module (e.g. testSetDatasets()), but then I'm worried about code's clarity. I'm interested in how pros handle such problems.
– rufus1530
Nov 22 '18 at 19:43
1
Tests should be as simple and autonomous as possible. Given that, a certain amount of duplication is often accepted. There's a good discussion on softwareengineering.stackexchange.com.
– Mark Meyer
Nov 22 '18 at 19:45