Assumptions are an underused feature of modern testing frameworks that should be more widely known. Briefly, an assumption verifies that conditions are right to execute the test. An assertion verifies that the test passes. If an assertion fails, the test failed, and we know the code is broken. If an assumption fails, the test was not run and the code may or may not be broken.
We’ve all had the distinction between “Is A” and “Has A” in object oriented programming drilled into us. “Is A” relationships call for inheritance. “Has A” relationships call for delegation. Some theorists will even bother to distinguish between “Is A” and “Is a Role Played By“. However, recently I’ve been wondering about the distinction between real “Is A” and “Represents A” relationships, and I wonder if it may help explain some otherwise confusing points.
Read the rest of this entry »
I’m in process of migrating this site to a new (and cheaper) host than GCP. This is not a quick or easy operation. More thoughts on that later. Meanwhile a few things are likely to be wonky. In particular:
1. Fixed – No SSL/https until the domain is migrated to a new registrar (about two weeks)
2. Fixed – IPv6 still goes to the old site.
3. Single page articles hit a critical error, perhaps due to an old theme that needs to be updated. Investigating…
Read the rest of this entry »
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?
Read the rest of this entry »
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.
Read the rest of this entry »
