-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple 'start' with single 'finished' #141
Comments
Or another event which indicates that more tests will be run |
You could already implement it like this:
Do you see any problems with this solution? |
I had that solution but the problem the same: No UI feedback: When I start running a test you replace all the icons to blue/pending ones. That is what I'm missing from the second run. Either in case of your solution (which was my old solution) and in case my new solution I cannot achieve that the icon of tests/suites became blue/pending. We can avoid the confusion by adding a new run event. With that I could send more test id's and you can change the icons: like |
Damn, I hadn't thought about the blue icons for scheduled tests. Looks like a |
I'm not sure about the naming though. extend, append, ... And since we are talking about events...
Events are the following in order:
The 'problem' here is 5 and 9. Sending those event's kills the blue/pending icon for the Dynamic1-1 and Dynamic2-1. (kills means changes to back to greyed normal). Eventually the tests were running so functionally it's ok, but not nice. I could: not sending 5,9 and 10,14 but then I need some extra logic to check that other tests will be run under that suite, etc.. totally makes sense. But.. I'm a lazy person and I've tried (only on my machine) the following:
And it seems working as I expected and good for me. Can you approve this abbreviated usage? (If yes, do I really need the TestRunStarted and TestRunFinishedEvent events at all for only static events? I guess yes because I can imagine TestRunFinishedEvent might indicates some post processing. Don't know) |
I came up with a solution that I like more than having a new event: As for sending test events without the corresponding suite events: yes, that is explicitly allowed (it's even mentioned in the documentation somewhere that the test suite events are optional). |
Great, Nitpicking a bit:
Then I can forget the |
Correct.
Currently you don't need them (I think - I've never tested this). However in that case it would just be a coincidence, not something I intentionally wanted to support. |
The latest version of Test Explorer's API contains the |
It does something but not bullet proof yet. Issue no.1: |
Thanks, I fixed this in 2.19.1. |
Hello, Still there is an issue. I start a long test and then I start shortly after another long test works. But If I start 3 long tests in a row the third one messes it up. :S |
I know it should be. an issue of the api, but since this is the implementation I though I open it here.
What is the situation?
Since it is allowed to click on play button next to test name while tests are already running, I though I can support sequentially adding new tests to the batch:
When
run
is called I just return a global promise and schedule the new tests.Works fine but on the ui it doesn't show much just when I send the running event about the new tests. If I could send multiple
started
events with a single finished, that would give enough flexibility.(Now the next
start
assumes that there is a missingfinished
. I guess this is an error handling logic now, so no one should depend on this.)Bests,
The text was updated successfully, but these errors were encountered: