Closed KeKs0r closed 8 years ago
If you can come up with a pretty way to display the information I'm open to a PR. But you may be better off just adding timers at the beginning and ending of your before and after.
Maybe as an additional "verbose option", so with -v you get the current version and then only add those runtimes when the test script is run with -vv.
Also from a plain formating perspective
Session Plugin
Set and query for sessions
✔ 63) should have a "setToken" function (0 ms)
✔ 64) should not be able to access secure route without token (1 ms)
✔ 65) should not be able to access secure route with the wrong token (3 ms)
✔ 66) should be able to access the route with access token (3 ms)
✔ 67) should be able to register >1 sessions for a single email/user (78 ms)
✔ 68) should be able to enter restricted areas after logging in (13 ms)
-------------------------
Session Plugin
● before (100ms)
● after (14ms)
Set and query sessions
● beforeEach (290ms, 6, ≈ 48ms)
So Basically an additional Section to see how long these additional hooks take. Then splitting it up, for which expirement they were run and also indicating for the *Each functions how often they were run.
Just wanted to mention, if you do end up implementing something please include it in the json reporter as well (not just the console).
On Wed, Jan 28, 2015 at 6:28 AM, Marc Höffl notifications@github.com wrote:
Maybe as an additional "verbose option", so with -v you get the current version and then only add those runtimes when the test script is run with -vv.
Also from a plain formating perspective
Session Plugin Set and query for sessions ✔ 63) should have a "setToken" function (0 ms) ✔ 64) should not be able to access secure route without token (1 ms) ✔ 65) should not be able to access secure route with the wrong token (3 ms) ✔ 66) should be able to access the route with access token (3 ms) ✔ 67) should be able to register >1 sessions for a single email/user (78 ms)
✔ 68) should be able to enter restricted areas after logging in (13 ms)
Session Plugin ● before (100ms) ● after (14ms) Set and query sessions ● beforeEach (290ms, 6, ≈ 48ms)
So Basically an additional Section to see how long these additional hooks take. Then splitting it up, for which expirement they were run and also indicating for the *Each functions how often they were run.
— Reply to this email directly or view it on GitHub https://github.com/hapijs/lab/issues/299#issuecomment-71827438.
Ok if ill do it, I try to consider other reporters as well. Im just very new to node in general and need to find some better understanding of it and the ecosystem first
While you're working on that part of the API, more verbose logging of crashes in before
et al and errors returned via the done
callback would also be nice.
Has this been actively approached? I'd like to see if I can sink my teeth into this.
No I did not yet have the time. Besides checking some of the lab code I have not really started. So if you want to tackle this, were probably all happy.
@KeKs0r: Cool. I've been having an issue with parallelism with Hapi tests but I feel like this would be a good segway to see if I could solve my own issue.
Closing as this has sat for a while and no activity. Feel free to open later if you do submit a PR @KeKs0r
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.
Hi,
I have an ever growing test suite of currently almost 100 test cases. They already take around 5 seconds. I would like to see where they spent there time. Unfortunately most of the "heavy lifting" is done in before() Hooks and then I just have a lot of assertions against the result. I would like to know if there is a possibility to not only show the runtime of single tests (with -v), but also the runtime of before(), beforeEach(), after() and afterEach() calls. If there is no such functionality yet, maybe it would make sense to add it.