Replies: 1 comment
-
I don't know if that could be a default rule. I think that it should be a custom rule because the But I think that before we can talk about that we should find a good way to implement a rule like that one. The current API doesn't allow that easily and the current proposal for 2.0 doesn't allow it either. Which API would be useful to handle this situation? A proposal: interface BatchRule : Rule, (Flow<KtFile>) -> List<Issue> {
override fun invoke(files: Flow<KtFile>): List<Issue>
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Opening this discussion since I'm noticing this pattern happening more frequently.
There seems to be an agreement in the Kotlin community to prefer fakes instead of mocks.
This means that you end up creating test utility classes that are implementation of interfaces with testing capabilities.
Example: for a
Clock
interface, you might have aFakeClock
that allows you to support your tests.I've noticed a phenomenon in big codebases where developers keeps re-creating fakes of the same instance instead of reusing them, so you end up having 6/7
FakeClock
all in different packages with slightly different capabilities.Ideally a
DuplicateFakeClass
rule could detect that the # of implementation classes for a given interface with the prefixFake
is at most 1.I'm curious to hear if someone else had the same experience.
Compliant
Non-Compliant
Beta Was this translation helpful? Give feedback.
All reactions