gildor
01/15/2018, 3:25 AMassertEquals("HI", "hi".toUpperCase())
assertEquals("1", "1".toUpperCase())
It’s easy to test function without side effects.
If a function has side effects you should probably refactor it to make testable. Always depends on your casekhoatd191
01/15/2018, 4:00 AMtrue
or false
and call update view.
so I want to do something like when(abc.validatexxx). thenReturn(true)
to avoid dependency for ValidationExtensionswhen
cause that String can’t be mocked.Max Russek
01/15/2018, 4:37 AMgildor
01/15/2018, 4:40 AMString.isValidUsername()
separately from your presenter. To test presenter do not mock abc
, but provide value from outside, for example by mocking View interfacekhoatd191
01/15/2018, 5:03 AMMax Russek
01/15/2018, 5:06 AMinterface Validator {
fun String.isValid(): Boolean
}
class Presenter(val validator: Validator) {
fun present() { if (user.name.isValid()) { ... } }
}
gildor
01/15/2018, 5:08 AMMax Russek
01/15/2018, 5:09 AMimport validator.isValid
or something like thatgildor
01/15/2018, 5:09 AMinterface Validator {
fun isValid(value: String): Boolean
}
Max Russek
01/15/2018, 5:10 AMgildor
01/15/2018, 5:31 AMhow many abstraction class we needYou need abstraction only in case when you want transparently replace one behaviour/logic with another one. If you don’t need validator abstraction in your presenter, and extension function
String.isValidUsername()
is enough for you, just use it. Write unit test for function itself (to check your username validation logic) and just provide different input to presenter, it should be easy, because you probably have View interface that returns current value of field
that later will be passed to validator and return result depending on content of your field.
So to test your code you don’t need to mock String, mock extension functions and Type Classeskhoatd191
01/15/2018, 6:11 AMgildor
01/15/2018, 6:15 AMkhoatd191
01/15/2018, 6:25 AMoleksiyp
01/19/2018, 9:23 PM