You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As remote taskfiles are on the roadmap it probably makes sense to be able to unit test taskfiles as well to ensure that any breaking changes are adequately accounted for as it can have wide ranging impacts.
Test Taskfiles should be in the same dir and follow the same convention as go tests. The test taskfiles will call all tasks the test prefix as well to determine which individual tasks within the taskfile should be tested
version: 'x'tasks:
test_task1:
- test -f somefile.txt
The tests should also be able to mock out sections where tasks other tasks rely on the execution of certain tasks (task1 calls task2) via - task: task2 (which actually makes an HTTP call or something) or the deps block:
With a format like txtar and Testscript it would become very easy to write test cases from a cli/user perspective. Currently the tests are mostly in task_test.go, and make reference to files in testdata folder - its a bit overwhelming.
I might write unit tests the "normal" way, making reference to files in testdata if necessary. But actually what I would rather write is E2E tests, using the simple Testscript method, because they prove task is working and also provide easy to understand examples.
Summary
As remote taskfiles are on the roadmap it probably makes sense to be able to unit test taskfiles as well to ensure that any breaking changes are adequately accounted for as it can have wide ranging impacts.
ref: #1317
Proposal
Test Taskfiles should be in the same dir and follow the same convention as go tests. The test taskfiles will call all tasks the test prefix as well to determine which individual tasks within the taskfile should be tested
example dir:
example task:
example test task:
The tests should also be able to mock out sections where tasks other tasks rely on the execution of certain tasks (task1 calls task2) via
- task: task2
(which actually makes an HTTP call or something) or thedeps
block:this of course would result in a subcommand of something like:
task --test -f ./...
The text was updated successfully, but these errors were encountered: