What is the best way to set up nested tests using mocha?
I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.
Let's imagine I want to run the following tests :
- user registers
- with invalid data
- it should fail
- with valid data
- it should succeed
- user logs in
- with invalid credentials
- it should fail
- with valid credentials
- it should succeed
- user lists stuff
- no stuff is available
- it should return empty list
- stuff is available
- it should return a list of stuff
- user adds stuff to his cart
- cart should show stuff
- no stuff is available
- with invalid credentials
- with invalid data
... and so on.
Looking at this, this could become a nasty mess of nested 'describe' and 'it'.
What would be the best way to write these tests without having a huge file containing the nested describes ?
(One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)
node.js mocha
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
add a comment |
I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.
Let's imagine I want to run the following tests :
- user registers
- with invalid data
- it should fail
- with valid data
- it should succeed
- user logs in
- with invalid credentials
- it should fail
- with valid credentials
- it should succeed
- user lists stuff
- no stuff is available
- it should return empty list
- stuff is available
- it should return a list of stuff
- user adds stuff to his cart
- cart should show stuff
- no stuff is available
- with invalid credentials
- with invalid data
... and so on.
Looking at this, this could become a nasty mess of nested 'describe' and 'it'.
What would be the best way to write these tests without having a huge file containing the nested describes ?
(One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)
node.js mocha
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
add a comment |
I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.
Let's imagine I want to run the following tests :
- user registers
- with invalid data
- it should fail
- with valid data
- it should succeed
- user logs in
- with invalid credentials
- it should fail
- with valid credentials
- it should succeed
- user lists stuff
- no stuff is available
- it should return empty list
- stuff is available
- it should return a list of stuff
- user adds stuff to his cart
- cart should show stuff
- no stuff is available
- with invalid credentials
- with invalid data
... and so on.
Looking at this, this could become a nasty mess of nested 'describe' and 'it'.
What would be the best way to write these tests without having a huge file containing the nested describes ?
(One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)
node.js mocha
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
I am currently working on some tests, and I'd like to create some structure where I can logically nest my system tests.
Let's imagine I want to run the following tests :
- user registers
- with invalid data
- it should fail
- with valid data
- it should succeed
- user logs in
- with invalid credentials
- it should fail
- with valid credentials
- it should succeed
- user lists stuff
- no stuff is available
- it should return empty list
- stuff is available
- it should return a list of stuff
- user adds stuff to his cart
- cart should show stuff
- no stuff is available
- with invalid credentials
- with invalid data
... and so on.
Looking at this, this could become a nasty mess of nested 'describe' and 'it'.
What would be the best way to write these tests without having a huge file containing the nested describes ?
(One of ideas was to use dependency injection - awilix - to create scopes and then trickle down the stuff like tokens, product lists, ...)
node.js mocha
node.js mocha
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
asked Nov 14 '18 at 23:16
Simon GueroutSimon Guerout
351213
351213
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.
My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.
For instance, the register and login tests would be rewritten as the following:
- Register user
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- Login with registered user
- Before Each hook - User should be registered
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- ...
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
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%2f53310195%2fwhat-is-the-best-way-to-set-up-nested-tests-using-mocha%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
I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.
My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.
For instance, the register and login tests would be rewritten as the following:
- Register user
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- Login with registered user
- Before Each hook - User should be registered
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- ...
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
add a comment |
I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.
My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.
For instance, the register and login tests would be rewritten as the following:
- Register user
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- Login with registered user
- Before Each hook - User should be registered
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- ...
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
add a comment |
I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.
My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.
For instance, the register and login tests would be rewritten as the following:
- Register user
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- Login with registered user
- Before Each hook - User should be registered
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- ...
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
I don't think there is some best way to do, what certainly matters is the readability and maintainability of your tests.
My approach is rather subjective but I would keep the tests as flattened as possible, by using hooks if needed.
For instance, the register and login tests would be rewritten as the following:
- Register user
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- Login with registered user
- Before Each hook - User should be registered
- it should succeed (test case#1)
- ...
- it should succeed (test case#n)
- it should fail (test case#1)
- ...
- it should fail (test case#n)
- ...
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
answered Nov 15 '18 at 0:02
MuratKMuratK
1655
1655
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
add a comment |
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
Thanks @MuratK, this is a pretty good approach. I am trying to make sure the state of the system generated by the previous tests is always consistent. For example, if I changed the login information, I'd rather avoid having to change my other tests, as they are not related to the login specifically. This is specifically a case of maintainability I am focusing on right now.
– Simon Guerout
Nov 15 '18 at 0:15
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
@Simon Guerout I understand your point of view. Be also aware that all your test logic seems to be dependant on the fact that the user gets logged in. If, for some reason, you want to test actions for unlogged users, you can't add them in your dependancy tree. At each nested step you reduce the scope of test possibilies you could write. By using hooks, you could just add or remove them.
– MuratK
Nov 15 '18 at 8:00
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
You pointed some really interesting concept : scope. This is pretty much my biggest focus, as what defines the actual order of the tests is the availability of a given scope. I have a good lead on something, will post a gist if it works out!
– Simon Guerout
Nov 15 '18 at 21:13
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%2f53310195%2fwhat-is-the-best-way-to-set-up-nested-tests-using-mocha%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
