proposal: `do_not_use_mockito`

[matanlurey]

do_not_use_mockito

Description

Do not use package:mockito.

Details

Mocking, or creating short-lived proxy objects that pretend to implement a type can be useful when testing certain contracts between related objects; for example, you may want to ensure that pet.eat(bowl) only calls the bowl.grab(...) method once with specific arguments (the pet's mouth size?).

However, mocking is generally extremely over-used. Typical apps and libraries usually have no need for mocking, and would be better served either by using the real object (especially for value-type immutable objects), and/or using or contributing to fakes - intentional sub-types intended for testing.

This lint would let teams avoid (or start avoiding additional) uses of mockito.

Kind

Style

Good Examples

N/A

Bad Examples

// LINT
import 'package:mockito/mockito.dart';

Discussion checklist

• [x] List any existing rules this proposal modifies, complements, overlaps or conflicts with.
• [x] List any relevant issues (reported here, the SDK Tracker, or elsewhere).
• [x] If there's any prior art (e.g., in other linters), please add references here.
• [x] If this proposal corresponds to Effective Dart or Flutter Style Guide advice, please call it out. (If there isn’t any corresponding advice, should there be?)
• [x] If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

/cc @srawlins

[srawlins]

I don't see us ever implementing this, but I like the thought. :)

[matanlurey]

What if I implemented it :)?

[bwilkerson]

I appreciate the offer, but it's not really about the cost of the initial implementation at this point. Unfortunately, the cost of maintaining the lints has increased as the language has grown, so we find ourselves needing to be more cautious about adding new lints.

We're in the process of defining the criteria we want to use going forward for allowing a lint to be added to the linter. We don't have a concrete set yet, but when we do we'll open it up for wider discussion and eventually publish them. As we start to use those criteria, the question will change from "is there any good reason to not add this lint" to "does it meet the criteria for new lints".

I agree with Sam that we likely won't add this lint at this point. The reason I say that is because I don't think it meets the bar in terms of bringing enough value to enough users. For most users it's enough to just not allow a package to have a dependency on mockito, and it isn't clear that users need a rule to enforce that given how often dependencies are typically added.

But I'm open to hearing if there's a criteria that you think we could apply uniformly when making these decisions that would justify the cost of adding this rule.

[incendial]

@matanlurey DCM provides a configurable rule for banning imports https://dartcodemetrics.dev/docs/rules/common/avoid-banned-imports, please take a look if you're not limited by the standard analyzer / linter 🙂