Allow to mock only traits and abstract classes without parameters

[goshacodes]

I wan't to allow mocking only traits and abstract classes without parameters.

Why I want to do this:

1. This change will encourage users to create interfaces for their classes and classes they have no access to, which is a good practice simplifying testing (also this complies to SOLID)
2. This will simplify maintenance of library, no need to handle each case internally (e.g. tagged parameters with supertagged or whatever else)

For closed classes without access users will create an interface, like this.

final class Foo(x: Int, y: Int) {
  def foo(x: String): Unit
}


// create adapter

trait FooAdapter:
  def foo(x: String): Unit


object FooAdapter:
  def apply(impl: Foo): FooAdapter = new FooAdapter { export foo.* }

This will generate a warning in 7.0.0 allowing users to migrate and will be removed in 8.0.0.

[barkhorn]

This is an interesting idea for sure and would eliminate some of the more complex workarounds. But one of the main points of mocking is often (in my experience) to hide collaborators that you have no control over - so, library APIs or stateful objects of some kind.
Of course writing a facade might be possible in some cases to create a deliberate boundary that you can then mock, but I wonder how many people would be willing to do that. As a developer, i would be weighing up the effort of doing that vs using a different framework that allows me to mock such complexity.
So as I see it, there is a risk that it makes ScalaMock easier to maintain and cleaner as a tool, but also less desirable to use at the same time.

[goshacodes]

Thought about it too. I guess this waits until I make some macro allowing to generate such interfaces for classes you have no control over.

Waiting for this: scala/scala3#21880

Linking this discussion also: https://contributors.scala-lang.org/t/pre-sip-adapters-to-simplify-testing-with-closed-classes/6978

This is an interesting idea for sure and would eliminate some of the more complex workarounds. But one of the main points of mocking is often (in my experience) to hide collaborators that you have no control over - so, library APIs or stateful objects of some kind. Of course writing a facade might be possible in some cases to create a deliberate boundary that you can then mock, but I wonder how many people would be willing to do that. As a developer, i would be weighing up the effort of doing that vs using a different framework that allows me to mock such complexity. So as I see it, there is a risk that it makes ScalaMock easier to maintain and cleaner as a tool, but also less desirable to use at the same time.