This is fine for this pull request, but in general, I think I'd put these helpers inside the companion objects of the Test* classes.

e.g.:

TestConsole.feedLines(...)

Then there's a logical place for users to look for them.

Yes I think this makes sense. One thing I am thinking about is whether it makes sense to have something like:

trait TestConsole extends Console {
  val console: TestConsoleImplementation
}

case class TestConsoleImplementation extends Console.Service[Any]

That way when we define these helper methods we can only depend on the specific environment type that these methods require and users could get the benefit of the method if they only depend on certain mock objects instead of the mock environment. Not sure about naming. What do you think?

Yes, you are right. Let's follow the ZIO conventions though:

trait MockConsole extends Console {
  val console: MockConsole.Service[Any]
}
object MockConsole {
  trait Service[R] extends Console.Service[R] { def feedLines(...) }

  def feedLines(lines: String*): ZIO[MockConsole, Nothing, Unit] = ...
}

Great. I'm on it!

One more organizational tip:

Let's rename TestEnvironment => TestEnvironmentInternals, and make it package private (private[test]).

Then inside zio.test.mock package object, we can do:

package object mock {
  val TestEnvironment: TestEnvironment = TestEnvironmentInternals.Value
}

Then a user has type TestEnvironment and can use value TestEnvironment, which is more Scala-idiomatic.

Hmm, actually, I'm not so sure about this, because TestEnvironment.Value has type Managed[...]. So let's leave this the way it is.

We can add this value in package object mock:

val TestEnvironmentManaged: Managed[TestEnvironment] = TestEnvironment.Value

In fact, it probably makes sense to rename TestEnvironment.Value to TestEnvironment.ManagedDefault (a managed, default test environment).