Channels
#announcements
- f
fellshard
08/02/2016, 12:02 AMWhat is this single real implementation in your mind? Something like JDBC Statement? - z
zoltu
08/02/2016, 12:03 AMSay you talk to S3, presumably you would mock/stub very close to the Amazon S3 library. - z
zoltu
08/02/2016, 12:04 AMYou have a very thin layer around S3 that defines your usage of it. - f
fellshard
08/02/2016, 12:04 AMSure. But does your application logic - for the most part - really care about S3? - z
zoltu
08/02/2016, 12:04 AMDoesn't matter. Pick where you want to mock/stub, I believe the argument doesn't change at all. - f
fellshard
08/02/2016, 12:04 AMS3 sits at the boundary. For all your application cares, it's working with the file system. - z
zoltu
08/02/2016, 12:04 AMYou could have a "Datastore" layer. But that layer has a single implementation which is the S3 datastore. - f
fellshard
08/02/2016, 12:05 AMOr a flat file. - z
zoltu
08/02/2016, 12:05 AMCopy codekotlin class Datastore { fun writeData(data: String) { amazonS3.write(data) } } - z
zoltu
08/02/2016, 12:05 AMI can't mock that. - z
zoltu
08/02/2016, 12:05 AMBecause it is closed. - f
fellshard
08/02/2016, 12:05 AMYup. So... - z
zoltu
08/02/2016, 12:06 AMSo I write an interface, that looks exactly like the only implementation of the interface. - z
zoltu
08/02/2016, 12:06 AMNow anytime I want to add a method (e.g.,
) I have to modify both.read - f
fellshard
08/02/2016, 12:06 AMCopy codeinterface Datastore { fun writeData(data: String) } class S3Datastore : Datastore{ override fun writeData(data: String) { amazonS3.write(data) } } class FSDatastore(dir: Directory) : Datastore { override fun writeData(data: String) { dir.writeToFile("myFile.dat", data) } } - z
zoltu
08/02/2016, 12:07 AMSo in your case you actually have 2 datastores. - z
zoltu
08/02/2016, 12:08 AMIn my experience, it is actually quite uncommon to actually have two implementations in application development. - z
zoltu
08/02/2016, 12:14 AMIt seems what you are arguing is that every class that is mocked should have multiple implementations. - f
fellshard
08/02/2016, 12:14 AMNot always - f
fellshard
08/02/2016, 12:15 AMOnly ones that lie in front of external dependencies. - z
zoltu
08/02/2016, 12:15 AMSo ignore everything except for the set of things that only have one implementation. - f
fellshard
08/02/2016, 12:15 AMThe rest turn out to be mockable with things like
fairly pragmatically.mock<Repository> - z
zoltu
08/02/2016, 12:15 AM^ Not true in Kotlin because closed by default. - f
fellshard
08/02/2016, 12:15 AMWhich usually hide vast logic and data. - z
zoltu
08/02/2016, 12:16 AMYou cannot do
unless you make it open and open all of its properties/functions.mock<Repository>() - z
zoltu
08/02/2016, 12:16 AMBut
is not safe to partially derive from, so it shouldn't beRepository
.open - f
fellshard
08/02/2016, 12:16 AMSo tune your testing mentality to match what's pragmatic. - z
zoltu
08/02/2016, 12:17 AMIt isn't my testing mentality. It is everyone else's. 😄 - z
zoltu
08/02/2016, 12:17 AMMy testing mentality says Integration Tests are the way to go. No one agrees, so I need patterns to deal with the rest of the world's mentality. - z
zoltu
08/02/2016, 12:17 AMUnit Testing is all the rage these days. 😛