[hamstergene]

It would be great if every complex or volatile third-party library came with its own mock and an abstract interface to which they both conform. Including pieces of language’s standard library itself.

It makes so much more sense this way:

- users don’t have to duplicate effort of writing more or less same mock/stub of the same library

- mock is forced to be up to date, because the library’s maintainers probably pay more attention to their release notes than you do

- no one knows the best choice of mocking approach/DSL than the library’s authors

- the adoption of inversion of control / dependency injection and comprehensive testing could be so much wider if writing a test didn’t require first solving an extra problem if how to mock something with complicated API and if it worth solving in the first place

[rileymichael]

this is what we do internally at $dayJob. the gradle java-test-fixtures plugin (https://docs.gradle.org/current/userguide/java_testing.html#...) creates a dedicated source set and wires up artifact publishing with a `test-fixtures` classifier. consuming a libraries fixtures is as simple as:

    // pull in some-library
    implementation("some-library-coordinates")
    
    // use its provided fixtures in tests
    testImplementation(testFixtures("some-library-coordinates"))

wish it was more common in the ecosystem, but it seems most folks aren't aware of it.