- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Looks to me like this will fail if any exception is thrown by "centralizedLogger.logAround(joinPoint);"
Admin
One would hope that an uncaught exception would fail the test no matter what BS is or isn't asserted down the line.
Admin
Perhaps that's entirely the point. Yes, it's 137% totally obscure, especially without comments, but ...
Admin
It is possible that my short tenure at a major financial firm was due to me informing my manager that although our "code coverage" was over 90% there were no assert statements.
Admin
Cobra effect. Anything you require, no matter how stupid, will be accomplished in the easiest possible way.
Admin
Bonus points for annotating the instance variable centralizedLogger with @InjectMocks - it won't mock anything since there is no other mocked instance injected - and then just overwriting that same variable in the method with a new ContralizedLogger instance.
Admin
SonarQube complains if a unit test does not have any assertions. Sometimes you just want to test that a piece of code doesn't throw any exceptions. You can use
assertDoesNotThrow(() -> /* code as lambda or method reference */)for that. It's of course possible to fool SonarQube and just wrap the entire test method inassertDoesNotThrow.Admin
I'll be honest, sometimes testing not throwing gives a measurably a better outcome than not testing at all. This is true especially if you have weakly-typed boundaries. Code-to-database and javascript-to-API are probably the most common to be weakly typed.
This is the biggest reason I don't mock services when it's possible not to. For example, I often create a real database schema using SQL Server LocalDB and use the real DB layer in my tests. A big point of fragility are those "hand-optimized" queries that sneak in because someone knows how to use the visual query builder, but doesn't know Linq. Running the happy-path test suite is a quick verification that no regressions were introduced at the data layer.
Admin
Mutation Testing FTW! See https://en.wikipedia.org/wiki/Mutation_testing for the basic concept, and if you want a deeper dive, pick from my playlist of conference presentations on it: https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS