I rely on your imagination to provide a more concrete example. If all your methods specify the type in the method name, then I'm thinking you need better naming conventions.
Enough with the '3 extra keypresses' bullshit.
Ba<autocomplete> badger = no<autocomplete>.<autocomplete> with explicit typing.
a<autocomplete> badger = no<autocomplete>.getB<autocomplete> without.
I make that 18 keypresses with explicit typing, 21 without, because explicit typing allows the IDE to know which method or methods you're going to be calling to get the value based on their return type, but inferred typing doesn't. Either way, if your productivity as a developer is based around three keypress differences in typing, then you're not doing enough
thinking.
Oh, and I just remembered my IDE will autocomplete simple variable names, so actually <autocomplete> will give 'badger' as the top match when declaring a variable of type Badger. That's another five keypresses saved, for a completely irrelevant 8-keypress advantage to explicit typing.
I'll listen to people who find the inferred typing looks more elegant in certain cases, even though I disagree for a lot of real cases that I come across. But really, the number of keypresses it takes to write the two versions is utterly irrelevant and
actually tends to come down on the side of explicit typing because it allows the IDE to be more intelligent more quickly.
Maybe I'll change my mind when I use a language in anger that supports inferred typing. But it won't be because of saved keypresses, I can promise you. It'll be because there are advantages in code maintenance and readability that I just don't see right now.
Which is fine. A lot of this stuff is entirely subjective, and a lot of it will depend on your coding background.
Explicit type declarations explicitly ensure that the type in question is what was intended. That's what they do. There's no
false confidence there - just a real confidence that you aren't assigning the wrong type anywhere (unless you explicitly choose to do so), or accidentally referencing objects at the wrong level of bstraction. It's very limited, but very good at catching such problems early. I don't see where you get the idea that this can instil a false level of confidence in the code.
Unit tests, however,
can to a point. There
will be cases where the tests all pass, but there's still a horrible bug. That's nothing to do with the tests not being written correctly; it's a necessary part of developing unit tests. What you should then do is create a new test for that bug, which may be an edge condition that hadn't been tested for previously, or a new type of input that hadn't been expected or encountered before, which improves your test suite. But to think (as some people wrongly do) that 'the tests all pass' is the same as 'there are no bugs'
is instilling a false sense of confidence - 'the tests all pass' means 'the tests all pass'. In fact, in some cases it means 'the tests all passed
this time' - that's normally a sign of badly written tests, of course.
Edit: My above keypress estimates were based on the flawed assumption that 'autocomplete' is a single keypress - obviously in most cases it will be two or even three. This doesn't change the basic point, and is still utterly irrelevant.