Use Task instead of Command about sbt-docker-compose

[fommil]

ok, reading 27 it sounds like you haven't discovered http://www.scala-sbt.org/0.13/docs/Howto-Dynamic-Task.html

I have also been guilty of using Command to "get it done" but almost everything is better as a Task.

[fommil]

that's because I don't think dockerComposeTest is a good way to do it. We use dockerComposeUp to bring up the docker compose fleet and then run integration and functional tests against those containers.

[fommil]

btw, another limitation of Command over Task is that there is only one docker-compose per Project. If it was a Task you could have a different composition for Compile vs Test vs IntegrationTest vs custom test phases (e.g. functional or performance tests).

[kurtkopchik]

Hi @fommil - Thanks for opening this issue. I would like to ultimately use Tasks as well but hit some limitations when I originally took this approach. This is detailed in issue #27.

[fommil]

ah, also pointed out here #27 (comment)

[fommil]

omg, the sbt docs are truly awful for dynamic tasks. I can explain a little clearer if you'd like to go that route.

[ches]

Agree this would be a nice improvement, for many good reasons discussed in #27 and @fommil's points.

Another is that, if you're able to hook naturally into the test in Test (or IntegrationTest) task then you can make use of testOptions in Test += Tests.Setup(/* ... */) and Tests.Cleanup, which can be pretty handy for system testing. A practical case I have is creating a keyspace (DB) on a stock Cassandra container, which can (and should) be done once per entire test run, not per suite like ScalaTest BeforeAndAfterAll would do. Multiple ways to skin this cat, but the sbt feature is an intuitive one that a user might expect to able to use.

[fommil]

Btw we ended up writing our own, see CakeDockerComposePlugin in sbt-cake and feel free to copy/paste into your project dir.

[insano10]

I would like to do test suite setup in sbt as mentioned by @ches so this would be a really nice thing to have.