Here’s the coverage report on a recent PR of mine:

All modified and coverable lines are covered by tests ?

    Comparison is base (a765aef) 85.95% compared to head (fe02e1b) 85.95%.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #546   +/-   ##
=========================================
  Coverage     85.95%   85.95%           
  Complexity     3480     3480           
=========================================
  Files           230      230           
  Lines          8225     8225           
  Branches        960      960           
=========================================
  Hits           7070     7070           
  Misses          865      865           
  Partials        290      290           

Precisely identical. What happened? Did I change a comment? Well, no. In fact I added tests for
situations that were not currently covered, so why didn’t coverage increase?

This entry was posted on Sunday, December 31st, 2023 at 9:29 am and is filed under Java, Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Reason 1: Mocking.

unittest.mock, Python’s mocking framework is so much more powerful than EasyMock, Mockito, or any other Java mock framework I’ve ever used. You can replace any method you like with essentially arbitrary code. No longer do you have to contort APIs with convoluted dependency injection just to mock out network connections or reproduce error conditions.

Instead you just identify a method by name and module within the scope of the test method. When that method is invoked, the actual code is replaced with the mock code. You can do this long after the class being mocked was written. Model classes do not need to participate in their own mocking. You can mock any method anywhere at any time, in your own code or in dependencies. No dependency injection required. You can even mock fields.

By contrast Java only lets you mock objects (not methods) and only when you have an available API to insert the mock in place of the real thing.

Reason 2: None is its own type.

This entry was posted on Sunday, December 10th, 2023 at 2:02 pm and is filed under Java, Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

Reason 1: Strong, static, compile time typing

I used to take Pythonistas at their word that they didn’t actually need strong, static compile time type checking. That was before I spent over a year writing Python more or less full time.

I am constantly blocked by not understanding which variables have which types. I am frequently spelunking through many levels of code and popping open the debugger to find out what type a variable actually has when. Not having explicit, enforced types makes code far harder to understand and edit.

Corollary: var is very bad idea for Java and should not be used.

This is well known in the Python community today. PEP 484 is basically an admission that inline typing is a necessity for robust code, and Guido has admitted as much. It’s why large Python shops like Meta and Google have invested in tools like Pyre and Pytype to add strong typing to the language. These tools help, but they’re not as good as Java’s strong, reliable, static type declarations and type checking.

Reason 2: Checked exceptions

This entry was posted on Sunday, December 10th, 2023 at 1:59 pm and is filed under Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.