Consider compat lib for seamless ScalaTest migration

[arturopala]

Hi @olafurpg ,

I just found about Munit at the ScalaLove conf and decided to give it a go in one of my projects using ScalaTest and WordSpec so far.

In due course, I have found a nice way to migrate to MUnit without rewriting a single line of my tests, except of course of changing class dependency to munit.FunSuite. That would make it easier for many people to try MUnit first and then eventually switch.

The resulting compatibility trait and an example test is presented here https://gist.github.com/arturopala/4cfd20de97006031329a946f08c54f20

Do you think it would make sense to have such a compatibility tool in a separate project?

Cheers, Artur

[olafurpg]

Thank you for taking the time to implement and share your experiments with building a ScalaTest compatibility API! I think this is an important discussion and I suspect several people are interested in using such a compatibility API because it would significantly reduce the cost of migration, it has at least come up several times on Gitter.

While I agree it's desirable to reduce the migration cost for ScalaTest users, I am still on the fence about including something like this in MUnit because it would mean that users face the choice of deciding what syntax they want to use: munit.FunSuite or AnyWordSpecCompat. An important goal for me personally is to make it easy for a beginner Scala developer to use MUnit without having to evaluate multiple testing DSLs.

That would make it easier for many people to try MUnit first and then eventually switch.

Do you have suggestions for how we can ensure this API is only used for the initial evaluation and not permanently after the eventual switch?

[arturopala]

@olafurpg I share your point of view and see possible win-win alternatives to shipping anything inside Munit:

1. separate, small scale library accompanying MUnit, replicating basic ScalaTest patterns with a limited set of popular Matchers

2. dedicated migration guide on the website, with live Scastie examples ready to use

The reasoning behind option 2 is that the effort and cost of coming with a comprehensive compat library might be substantial, while a simple library might not be of real use and disappointing in the long run. Having some simple seeds to copy, like AnyWordSpecCompat, might be a quicker and more scalable solution, allowing developers to gradually migrate and scale down to the minimal set of matchers, which might be a different target for different people.

[olafurpg]

dedicated migration guide on the website, with live Scastie examples ready to use

Sounds good. I'm OK with linking to example code that users can copy-paste. Do you have a preference between writing the code examples on Scastie or in the MUnit website? All of the code examples on the website are typechecked. I'm OK with adding a dependency on ScalaTest in the docs project.

I primarily want to avoid publishing artifacts with a ScalaTest since that would mean we take on the burden of maintaining a compatibility layer for ScalaTest, which as you say is hard to deliver 100%.

[olafurpg]

Closing this as "wontfix". The ScalaTest migration guide has been expanded with more details https://scalameta.org/munit/docs/scalatest.html thanks to the contribution in #166 and #164

Additionally, I'm open to merge a PR based on the work in #191 adding Scalafix migration rewrites from ScalaTest to MUnit.