-
Notifications
You must be signed in to change notification settings - Fork 9
Testing Rules #24
Comments
When you say 'function names' is the assumption that test modules are a 1:1 correlation with library modules? As in, if |
So like in |
Right, I was getting more at naming and splitting up of test modules. |
Ah. Yea I believe that is in the spirit of what we are trying to do. |
I thought so, definitely worth documenting though so we can be sure it's consistent everywhere |
Yeah I think the flow is going to be discuss it here, and once it's nailed down, have a wordsmith write something up over in /contrib |
@nlf if you are describing a class method, there should be one |
@hueniverse right, but in that case you would have |
I like to keep test files mapped to the source files. Half our modules have a single index.js. |
Could someone elaborate bit more on rule 3? Does outside of any describe basically mean inside the top describe? Like inside In any case I struggle to find clear line between what should go inside methods sections and what should go to class section. Here is the example from catbox-mongodb that I don't understand:
and this is in
These two tests seems to have identical (or almost identical) scope.. |
Does my question make sense? In that particular example in my previous post I don't understand if its intention to have the same test basically twice there or just oversight. And still I would like to hear what decision process you have when you organize tests. In trivial cases its clear. For example when it just test that particular function, it is obvious why its in method section like this:
But it is not clear when you for example test both get and set in one test, because they work together. In such case I would put it to class section. I am pretty new to writing these tests and just want to make sure that I follow hapi guidelines when creating new tests. |
@arb Can you address the questions above? |
I think the rule means that basic integration tests (like "it works") don't need to be nested inside an outer Also, there was conversation about lab auto generating the outer level describe, it doesn't yet, so that could be adding to the confusion as well. I've open an issue on lab to address this. As for testing two things in one test... you generally should avoid doing that. Each test should really be testing one thing. So in your |
Create a document that lays out the "rules" for lab test layouts for the hapijs universe. The current proposal is:
Thoughts? Concerns? Clarifications?
The text was updated successfully, but these errors were encountered: