4 ms·
What’s cheaper to own though - a whole test library / framework (assuming you don’t use any other feature), or a simple interface? I’m generally hesitant to ad
by CraigJPerry 7y ago
What’s cheaper to own though - a whole test library / framework (assuming you don’t use any other feature), or a simple interface?
I’m generally hesitant to add test libraries if there’s an easy design choice alternative that keeps the code simpler.
- organsnyder 7y agoMockito is a single pom.xml (or build.gradle) entry. edit: Not "Moquitto".
- CraigJPerry 7y agoIt is - but my point is about complexity not ease. The fact that dependency is versioned separately from your code base is one source of complexity that it adds. The fact that it has many lines of code is another complexity. It is however often easier, even although i'm advocating very small self-written test doubles, they are still less easy than using mockito.
- organsnyder 7y agoIt's a dependency that's only needed during testing, though—it's not shipped with production artifacts.
- CraigJPerry 7y agoThat argument doesn't address complexity. Tests are part of the system.
- MockObject 7y agoClose! That's Mockito. https://site.mockito.org/ https://site.mockito.org/
- organsnyder 7y agoOops. Haven't done Java programming full-time since last year, but I did set up a home MQTT broker recently...
- MockObject 7y agoAdding interfaces whose only purpose is unit tests is not keeping the code simpler. Using a test library that automatically generates mocks for unit testing is what keeps the code simpler.
- CraigJPerry 7y ago>> automatically generates mocks for unit testing is what keeps the code simpler You're possibly confusing easy with simple but adding a versioned library of some thousands of lines of code to a project is in no objective way simpler than adding a small test double which you wrote.
- MockObject 7y agoYes, it is, in the only objective way that people actually care about: the size and simplicity of the source code. (What people don't care about is the size of libraries that are scoped for the test context only, and don't even impact artifact size at all.) Also, a Mockito mock is simpler in usage than a hand-written and normally instantiated test double.
- CraigJPerry 7y agoRipping off the classic talk by Rich Hickey: Simple - composed of a single element; not compound Complex - consisting of many different and connected parts Easy - achieved without great effort; presenting few difficulties. This is not as easy but is simple. It is explicit, fundamental Java. public void allocationOnlyPossibleWhenOpen() { LocalDateTime expected = LocalDateTime.now(); TimeAllocator sut = new TimeAllocator(new Clock() { public LocalDateTime getTime() { return expected; } }); sut.setOpen(false); assertThat(sut.allocate()).isNull(); sut.setOpen(true); assertThat(sut.allocate()).isEqualTo(expected); } This is easier but more complex. It depends on a multi-thousand line library with its own API. public void allocationOnlyPossibleWhenOpen() { LocalDateTime expected = LocalDateTime.now(); Clock mockClock = mock(Clock.class); when(clock.getTime()).thenReturn(expected); TimeAllocator sut = new TimeAllocator(mockClock); sut.setOpen(false); assertThat(sut.allocate()).isNull(); sut.setOpen(true); assertThat(sut.allocate()).isEqualTo(expected); } The 2nd example has: A versioned external dependency, externally versioned == opportunity for future conflict. Remember the java logging library wars? Today it's trivial to encounter conflicting spring dependencies on your classpath A complex (but convenient) reflection based implementation, the object has non-obvious behaviour with a clever implementation An entire api surface distinct from the components of your software system Tens of thousands of lines of opportunity for bugs, security risks or just plain old $$ cost to hide in Once you're able to see the world in complexity, it opens up a whole new dimension of cost & quality for your code. All this said, in practice complexity is just a consideration. Often the complexity is worth paying. I don't want to risk the impression that i'm saying never use mockito. If my argument is anything then it's consider the impact of complexity.
- ses1984 7y agoSure pulling in a giant magical reflection heavy test framework has costs but I think it's well worth it.