Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stepping down as Mockito maintainer after ten years

github.com

Post reply on HN
Print view View original

171–180 of 220 posts

Re: Stepping down as Mockito maintainer after ten years

#171

Post by 3uler »

MrJohz wrote: post #158
throwaway7783 wrote: post #150

Earlier quoted context omitted.

I am unsure I follow this. I'm generally mocking the things that are dependencies for the thing I'm really testing. If the dependencies are proper interfaces, I don't care if it's a fake or a mock, as long as the interface is called with the correct parameters. Precisely because I don't want to test the implementation details. The assumption (correctly so) is that the interface provides a contract I can rely on. In y…

The point is that you probably don't care that much how exactly the dependency is called, as long as it is called in such a way that it does the action you want and returns the results you're interested in. The test shouldn't be "which methods of the dependency does this function call?" but rather "does this function produce the right results, assuming the dependency works as expected?". This is most obvious with com…

The fakes vs mocks distinction here feels like a terminology debate masking violent agreement. What you’re describing as a “fake” is just a well-designed mock. The problem isn’t mocks as a concept, it’s mocking at the wrong layer. The rule: mock what you own, at the boundaries you control. The chaos you describe comes from mocking infrastructure directly. Verifying “deleteUserById was called exactly once with these params” is testing implementation, not behavior. Your HashMap-backed fake tests the right thing: is the user gone after the operation? Who cares how. The issue is finding the correct layers to validate behavior, not the implementation detail of mocks or fakes… that’s like complaining a hammer smashed a hole in the wall.

Re: Stepping down as Mockito maintainer after ten years

#172

Post by BlackFly »

davnicwil wrote: post #58
BlackFly wrote: post #33

Earlier quoted context omitted.

An anonymous inner class is also ephemeral, declarative, inline, capable of extending as well as implementing, and readily readable. What it isn't is terse. Mocking's killer feature is the ability to partially implement/extend by having some default that makes some sense in a testing situation and is easily instantiable without calling a super constructor. Magicmock in python is the single best mocking library though…

> What it isn't is terse Yeah, it's funny, I'm often arguing in the corner of being verbose in the name of plain-ness and greater simplicity. I realise it's subjective, but this is one of the rare cases where I think the opposite is true, and using the 'magic' thing that shortcuts language primitives in a sort-of DSL is actually the better choice. It's dumb, it's one or two lines, it says what it does, there's almost…

I cannot put my finger on it exactly either. I also often find the mocking DSL the better choice in tests.

But when there are many tests where I instantiate a test fixture and return it from a mock when the method is called, I start to think that an in memory stub would have been less code duplication and boilerplate... When some code is refactored to use findByName instead of findById and a ton of tests fail because the mock knows too much implementation detail then I know it should have been an in memory stub implementation all along.

Re: Stepping down as Mockito maintainer after ten years

#173

Post by Sankozi »

pjc50 wrote: post #40
nsxwolf wrote: post #32

Earlier quoted context omitted.

Absolutely the worst. 1000 line test setups that shatter into pieces the instant you try to make the simplest change to a function. Makes refactoring an absolute nightmare.

What's specifically bad about Mockito here? Poor defaults for mocks?

People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.

You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).

Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).

Re: Stepping down as Mockito maintainer after ten years

#174

Post by derriz »

throwaway7375 wrote: post #170
derriz wrote: post #159

Earlier quoted context omitted.

I used ResultSet because the comment above mentioned it. A clearer example of what I’m talking about might be say you replace “x.size() > 0” with “!x.isEmpty()” when x is a mocked instance of class X. If tests (authored by someone else) break, I now have to figure out whether the breakage is due to the fact that not enough behavior was mocked or whether I have inadvertently broken something. Maybe it’s actually impor…

What is the alternative? If you write a complete implementation of an interface for test purposes, can you actually be certain that your version of x.isEmpty() behaves as the actual method? If it has not been used before, can you trust that a green test is valid without manually checking it? When I use mocking, I try to always use real objects as return values. So if I mock a repository method, like userRepository.se…

The alternative to what? Using mocks?

For example, one alternative is to let my IDE implement the interface (I don’t have to “write” a complete implementation), where the default implementations throw “not yet implemented” type exceptions - which clearly indicate that the omitted behavior is not a deliberate part of the test.

Any “mocked” behavior involves writing normal debuggable idiomatic Java code - no need to learn or use a weird DSL to express the behavior of a method body. And it’s far easier to diagnose what’s going on or expected while running the test - instead of the backwards mock approach where failures are typically reported in a non-local manner (test completes and you get unexpected invocation or missing invocation error - where or what should have made the invocation?).

My test implementation can evolve naturally - it’s all normal debuggable idiomatic Java.

Re: Stepping down as Mockito maintainer after ten years

#175

Post by akoboldfrying »

wpollock wrote: post #139
akoboldfrying wrote: post #138

Earlier quoted context omitted.

It doesn't have to be a breaking change -- an empty result set could still be allowed . It could simply be a perf improvement that avoids calling an expensive function with an empty result set, when it is known that the function is a no-op in this case.

If it's not a breaking change, why would a unit test fail as a result, whether or not using mocks/fakes for the code not under test? Unit tests should test the contract of a unit of code. Testing implementation details is better handled with assertions, right? If the code being mocked changes its invariants the code under test that depends on that needs to be carefully re-examined. A failing unit test will alert one…

The problem occurs when the mock is incomplete. Suppose:

1. Initially codeUnderTest() calls a dependency's dep.getFoos() method, which returns a list of Foos. This method is expensive, even if there are no Foos to return.

2. Calling the real dep.getFoos() is awkward, so we mock it for tests.

3. Someone changes codeUnderTest() to first call dep.getNumberOfFoos(), which is always quick, and subsequently call dep.getFoos() only if the first method's return value is nonzero. This speeds up the common case in which there are no Foos to process.

4. The test breaks because dep.getNumberOfFoos() has not been mocked.

You could argue that the original test creator should have defensively also mocked dep.getNumberOfFoos() -- but this quickly becomes an argument that the complete functionality of dep should be mocked.

Re: Stepping down as Mockito maintainer after ten years

#176

Post by vips7L »

gf000 wrote: post #168
vips7L wrote: post #95

Earlier quoted context omitted.

I'm not sure Kotlin is a hack, but it's growth is directly related to Java not being able to deliver on simple features that would help the day to day lives of developers. So I also can't blame anyone for moving on from the language. I get frustrated with it all the time, especially when Kotlin shows that some feature could work perfectly fine. Here are some examples that have hit the graveyard: It's been 2 years sin…

Sure there are pain points in Java, but I definitely wouldn't want the language to introduce 15 new features each having only a tiny benefit. Based on your other comment you prefer "fat" languages like kotlin and C# - and that's fair. I find languages with less, but more powerful features far more elegant and while Java has its fair share of historic warts, modern additions are made in a very smart way. E.g. switch e…

I’m sorry, but null restricted types, string templates, basic json support, and fixing the broken exception system isn’t “fat”. They’re the basics of a functioning language.

Re: Stepping down as Mockito maintainer after ten years

#177

Post by supriyo-biswas »

EdwardDiego wrote: post #156
throwaway7783 wrote: post #120

Earlier quoted context omitted.

I still miss dependency injection in Python

FastAPI rolled their own using annotations. It's... ...okay.

Unfortunately it also constructs dependencies per request instead of singletons, so you have to rely on hacks like `@lru_cache(maxsize=1)` on the factory functions.

I'd really like to see a Python framework that embraces class-based controllers to do away with this problem; beyond that writing a dependency injection system is not too difficult of a task (the last time I did it for a hobby project many years ago, it was around ~150 lines of code).

Re: Stepping down as Mockito maintainer after ten years

#178

Post by gf000 »

vips7L wrote: post #176
gf000 wrote: post #168

Earlier quoted context omitted.

Sure there are pain points in Java, but I definitely wouldn't want the language to introduce 15 new features each having only a tiny benefit. Based on your other comment you prefer "fat" languages like kotlin and C# - and that's fair. I find languages with less, but more powerful features far more elegant and while Java has its fair share of historic warts, modern additions are made in a very smart way. E.g. switch e…

I’m sorry, but null restricted types, string templates, basic json support, and fixing the broken exception system isn’t “fat”. They’re the basics of a functioning language.

Null restricted types are indeed important and while null check plugins exist for Java, this is a big step in the good direction by kotlin.

String templates are valuable syntactic sugar, but that's it.

There are a bazillion JSON libraries with at least 3-4 absolutely stellar ones. I don't really see it that big of a limiter.

And if you mean checked exceptions, that's controversial to claim it's all bad. But some ergonomics improvements would be better.

Re: Stepping down as Mockito maintainer after ten years

#179

Post by hcfman »

1a527dd5 wrote: post #75

Running open source _anything_ looks exhausting from the outside. I don't know why owners/maintainers show grace like this. For me; I would say I'm done and hand it over or just archive the repo. Hope Tim finds a measure of sanity after he steps down.

I think showing grace was the right way to do things. It preserves the value of all the effort he put into it. When you work on things that long they are part of you. Like your baby, you don't toss them aside carelessly, it's painful to do that I'm sure.

Well done for Tim for being one of those guys that worked so hard for others to benefit. Tim, you've done something you can be deeply proud of forever, no matter how it ended.

Re: Stepping down as Mockito maintainer after ten years

#180

Post by bluGill »

bccdee wrote: post #147
bluGill wrote: post #70

Earlier quoted context omitted.

90% of the time (or more): you don't. The real thing is perfectly fine in a test with the right setup. Fileio is fast, I just need a test file in a tempdir. databases are fast, I just need an easy way to settup my schema. Sometimes I need the isolation but normally I do not.

What if you're calling an API? How do you test a tool that does a bunch of back-and-forth with another service without actually hitting that other service? Do you have to spin up your entire k8s ecosystem in a local cluster just to validate that the logic in one function is sound? Do you have to deliberately misconfigure it in order to test that your function handles errors properly? More broadly, suppose foo() has a…

I have never done a full k8s but I have started dbus on a non-standard port for isolation.
Post reply on HN