Show runtime for before(), after() etc.

[KeKs0r]

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.

[geek]

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.

[KeKs0r]

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.

[lloydbenson]

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.

[KeKs0r]

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

[garthk]

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.

[jalcine]

Has this been actively approached? I'd like to see if I can sink my teeth into this.

[KeKs0r]

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.

[jalcine]

@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.

[geek]

Closing as this has sat for a while and no activity. Feel free to open later if you do submit a PR @KeKs0r

[lock[bot]]

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.