wasyl
03/17/2021, 4:56 PMsam
03/17/2021, 5:05 PMchristophsturm
03/17/2021, 5:15 PMsam
03/17/2021, 5:15 PMwasyl
03/17/2021, 5:16 PMmockito
can by default only mock interfaces and open classes, which is good enoughsam
03/17/2021, 5:18 PMwasyl
03/17/2021, 5:18 PMsam
03/17/2021, 5:18 PMwasyl
03/17/2021, 5:21 PMsam
03/17/2021, 5:22 PMchristophsturm
03/17/2021, 5:23 PMsam
03/17/2021, 5:24 PMJavier
03/17/2021, 5:25 PMwasyl
03/17/2021, 5:25 PMsam
03/17/2021, 5:27 PMwasyl
03/17/2021, 5:29 PMsam
03/17/2021, 5:29 PMwasyl
03/17/2021, 5:32 PMsam
03/17/2021, 5:35 PMchristophsturm
03/17/2021, 6:00 PMsam
03/17/2021, 6:00 PMthanksforallthefish
03/18/2021, 6:56 AMmock a method, invoke the method, method does what I wanthow is this different than a fake though? implement a fake, call the method, it does what you want. I (am starting to) understand the no-mock movement, but I don’t see fakes as a replacement. mocks are just so much more flexible and can keep production code much more lean.
class DoSomethingUseCase(val repo: Repository) {
fun doSomething(entityId: Id) {
val entity = repo.get(entityId)
entity.doSomething()
}
}
imagine this trivial example, the only way I see to practical drop the mock of Repository
is to drop the unit test for DoSomethingUseCase
and replace with an integration testwasyl
03/18/2021, 7:00 AMinterface Foo { fun doThing() }
then using fake vs mock will have little practical difference. But consider
interface Store {
fun save(value: String)
fun read(): String
}
When mocking this class you’ll either have to reimplement it basically but using mocks (usually it’s just carefully mocking read()
function to return whatever one expects to have been stored) or you’ll end up testing all possible combinations of store/save return values, some of which might not make senseclass FakeRepository : Repository {
private val entities = mutableMapOf<Id, Entity>()
fun store(id: Id, entity: Entity) {
entities[id] = entity
}
override fun get(id: Id) = entities[id]
}
this is simple and guaranteed to work as expected, honestly I don’t see reason to use a mock even in such simple scenariothanksforallthefish
03/18/2021, 7:06 AMwasyl
03/18/2021, 7:09 AMthanksforallthefish
03/18/2021, 7:10 AMwasyl
03/18/2021, 7:14 AMfakes are just another (now untested) implementation of some codefair point, my take is that if the fake is big enough to need a test then it implements interface that’s too big anyway, and the simple implementations are easily verifiable. I did hear an idea of testing fakes using the same tests as real implementations, but haven’t really seen a real example and I’m not sure it’s possible
christophsturm
03/18/2021, 9:07 AMwasyl
03/18/2021, 9:10 AMUnit
?christophsturm
03/18/2021, 9:12 AMwasyl
03/18/2021, 9:15 AMchristophsturm
03/18/2021, 9:15 AMsam
03/18/2021, 9:38 AMthanksforallthefish
03/18/2021, 12:53 PMchristophsturm
03/18/2021, 12:57 PMdave08
03/18/2021, 1:00 PMchristophsturm
03/18/2021, 1:31 PM