refactor: unify how executor tests are written

[pd93]

Currently we have a couple of different ways of writing tests in task_test.go. Some use the the fileContentTest template, some directly craft and run an Executor.

This is a draft PR for a new test type called TaskTest. The idea is that this is a "do everything" testing suite for the Executor. Instead of relying on handcrafted outputs written inside the go file or creating special taskfiles that output content to a file, it uses goldie to create test "golden files". The API uses functional options and post-processing functions to setup tests.

As there are a lot of tests in here, I wanted to gather some feedback on the approach before I continue. I'm also interested in splitting this file up as its currently at over 3400 lines long, but looking for some opinions on the best way to do this. I had considered renaming the existing testdata folder to tests and moving these tests there alongside their taskfiles, but this doesn't feel very "go-like"?

[vmaerten]

Hey @pd93
First of all thanks for doing this !! I had to write / modify some tests recently and it's painful

I'm also interested in splitting this file up as its currently at over 3400 lines long, but looking for some opinions on the best way to do this. I had considered renaming the existing testdata folder to tests and moving these tests there alongside their taskfiles, but this doesn't feel very "go-like"?

I totally agree with you about splitting this file. It may not be very "Go-like," but it makes everything more readable. Having everything in one place is convenient. Every time I work on tests, I find it somewhat difficult to switch between the test file and the testdata directory.

Also, having the golden file named this way makes it easy to identify.

Last but not least, the diff is amazing :

At work, we use cupaloy, which is also a great tool for handling snapshots.

I am totally in!