Use pre-run task exactly as found, instead of creating a new one.

[bzarco]

Not all task options can be set using the constructor (e.g.
presentationOptions), so instead of manually copying all, which is prone
to error as more may be added, use the task as found.

Note that for some reason vscode fails with "Task not found" when
executing the task with a populated __id (maybe only with code-workspace
tasks?), the simplest thing that fixes it is to call the name setter,
which calls task.clear().

[bzarco]

Do you see any reason to not do this? I noticed because the task output wasn't being cleared, even though I have "presentation": { "clear": true } in the task. We could obviously call resolvedTask.presentationOptions = found.presentationOptions, but I don't know if any other options are also missed when using the constructor...

The calling Task.name setter workaround is probably due to a vscode bug around workspace files, I have found a few already... I will see if I find the issue and will send a PR to vscode.

[matepek]

I was experimenting and it wasn't work work for me at some point and I think I forget to experiment more with that. On the released version it is working.

Also in debug mode vscode doesn't list my tests at first.. I have to modify them manually and then its ok.

Also I have this message:

Error: the task 'Workspace: Touch' neither specifies a command nor a dependsOn property. The task will be ignored. Its definition is:
{
    "type": "shell",
    "id": "shell,touch,/path1,/path2,",
    "problemMatcher": [],
    "label": "Workspace: Touch"
}

I don't get it why.

With touch I can reproduce your issue. Basically what happens is that when your task runs it modifies (rebuild) the executable. Test execution happens and then for the file system watcher change event the extension reloads the tests.
Well it is like this by design.. I'm thinking about it..

[bzarco]

Ahh that makes sense... So it is a race condition between the file watcher and the test run, and if the test run finishes first then the watcher will retire it? Interestingly I think that wasn't happening with the way I implemented it, probably because the task was being run earlier and decoupled from the tests?

[matepek]

There is a main task queue. "run" and "reload" and "debug" are put in the queue.
(Search for _mainTaskQueue in TestAdapter.ts)
It is to prevent parallel concurrency issues. In my case the tasks run under the "run". The "reload" stage cannot happen until the "run" finishes. In your case you were running the tests out of queue.

Having the task execution under the "run" has another advantage: the blue icon and the cancel actually cancels the tasks too. Tasks can be killed from the terminal too, so this is not a must have, but it would be nice to have like this.

I'm thinking about our options here...

[bzarco]

Sounds good, thanks for explaining. I agree that changing the test icon and cancel is a nice touch, I actually really like it... It also shows the failed state and prints the failure in the log when the task fails.

[matepek]

I made some nifty changes in version 3.1.

My favorite: If you click run a suite (not a test) and your tasks rebuild the executable and there is a new task part of that suite then that will be included in the run too.

Happy coding

[bzarco]

Thanks Mate!! It is working great! :)