Output handler refactoring #345
Conversation
dg
force-pushed
the
master
branch
2 times, most recently
from
715ed4e
to
334dc33
Compare
src/Runner/Test.php
Outdated
| */ | ||
| public function withResult($result, $message) | ||
| { | ||
| # TODO: Vyjimku, pokud je test failed? |
There was a problem hiding this comment.
I'd throw an exception if the test already has any result
src/Runner/Test.php
Outdated
| class Test | ||
| { | ||
| const | ||
| NO_RESULT = 0, # TODO: lepsi jmeno |
src/Runner/Runner.php
Outdated
| @@ -95,7 +90,7 @@ public function run() | |||
| $handler->begin(); | |||
There was a problem hiding this comment.
I'd love to be able to get $this->jobCount in here, but that would mean moving this call after $this->findTests() in which results may already be sent to output. They'd have to be buffered somehow. What do you think?
There was a problem hiding this comment.
More precisely, the most perfect scenario would be if I could get an array of all Tests so that the output handler could process them (similarly to what I did in #335). It would make sense to me if findTests created and actually returned found Tests, and the while loop iterated over them instead of Jobs. But that would mean that Tests would somehow have to be aware of their respective Jobs, which is something you didn't quite like
There was a problem hiding this comment.
I tried to outline one possible (and sensible to me) solution in milo#1
src/Runner/Test.php
Outdated
| /** | ||
| * @return array | ||
| */ | ||
| public function getJobArguments() # TODO: tohle sem asi nepatri |
There was a problem hiding this comment.
Now that the arguments are abstracted in an array, maybe Job should just call getArguments() and do this formatting itself? It feels coupled to the way Jobs are executed.
milo
force-pushed
the
output-handler-refactoring
branch
from
9634df4
to
61c4ca5
Compare
milo
force-pushed
the
output-handler-refactoring
branch
from
61c4ca5
to
c56cab9
Compare
|
@jiripudil Thanks for review. |
|
@milo You're welcome, sorry it took me so long. What do you think of the idea behind milo#1 ? It makes sense to me because some output handlers might use the information about the tests before printing the results. I know it's a BC break, as is the rest of this pull, but since it targets 2.0, I think it's justifiable. Although a lot of the internal code has changed, the changes to the public API ( I know @mrtnzlml has written a custom handler. As for others, maybe you could ask on Twitter? |
The output handler is a deliberate step back: it is very simple as it just prints the results without grouping them in any way. But, on a might brighter note, this approach works with pretty much any version of Nette Tester 🎉 (a more intelligent output handler implementation waits for the resolution of nette/tester#345) Breaking change: a user-defined setup script, previously configured via --setup entry in "Tester options", must now be provided in a separate "User setup script" option in the Run Configuration dialog, otherwise tests and/or the plugin might not work as expected.
|
btw it seems that the |
dg
force-pushed
the
master
branch
3 times, most recently
from
c7e8a12
to
df5e87f
Compare
|
Closing in favour of #370 |
This is how I image solution for #326. So, the main purpose is to provide more information for OutputHandler.
This is a WIP concept with many TODOs to solve. One problem is, that the new
Testclass shares many common properties withJoband I'm not sure if it's OK.