• The Apple Programmer Playlist

    A collection of songs in my iTunes library with titles that resonate with the Dogcow:

     

    https://open.spotify.com/user/12159781656/playlist/1V4nAmPs3Hdg7z5EnazlGL?si=QlvLmN-MSc-MueacNfem2Q

     

  • Jemilla

    JemillaSmallAina occasionally allows me to share their artwork.  Today is one of those lucky days.

     

    JemillaSmall

  • Aggretsuko Rocks

    Meanwhile, Aina and I are enjoying Netflix’s new series, Aggretsuko ( アグレッシブ烈子 ), about a anthropomorphic red panda office worker in Tokyo who is into Death Metal karaoke:

    NewImage

  • Taxonomy of Test Categories, Part 2

    There are tests named for the object of the test:

    library test, API test, installer test, UI test, class test, all of which might be component tests

    There are tests named for some aspect of functionality or performance:

    integration test, end-to-end test, accessibility test, localization test, network test, all of which might be functional tests

    There are tests named for some aspect of performance:

    stress test, leak test, speed test, fuzzing test, all of which might be performance tests

    There are tests named for when the test is run:

    build-time test, runtime test, CI test, daily test

    There are tests named for why the test is being done:

    smoke test, acceptance test, build verification test

    There are tests named for conditions under which the test is done:

    local test, simulator test, device test, cloud test, black box test, low memory test, slow network test

     

    If your team is using the phrase ‘unit test’ in any situation where one of these other terms might be more descriptive, you might save yourselves some misunderstanding by using that other term instead.

     

    Have more test categorizations that I can add? Let me know!  

     

  • Taxonomy of Test Categories

    I spent some time with a co-worker today trying to figure out where “Unit Tests” end and where “Integration Tests” begin. It turned into an interesting enumeration of various criteria for categorizing tests, because I was having trouble understanding how the team actually thought about what a “unit test” was.

    Unit Test is such a wobbly concept – it feels to me that most people think the term has a more specific meaning that it really does, so its worth delving into the spectrum of meaning.

    Assertion A unit test is a test that tests only a particular component

    The problem is that ‘component’ is an ambiguous term. Is it a test of a single class? A single file? Some developers try to break down functionality into very small classes – does this mean that tests need to be broken down as well, beyond the point of having a useful scope of testing? Or the component can be as large as it needs to be for a given test – would a whole app could be a ‘component’?

    Assertion A unit test is a test that has no dependencies beyond the dependencies of the thing that is being tested.

    This sounds good, and yet most unit tests have dependencies on unit test utilities like Mock classes or other test frameworks. So, we could use this definition if we add an exception that ‘certain test frameworks are exceptions’.

    Still, however, this is problematic: this just means that ‘the thing being tested’ can just be redefined to be as large as the scope of the test. That doesn’t help differentiate between what a unit test is or isn’t.

    Also problematic: different systems have different ideas of what it means to have dependencies: Does it mean loading of additional NuGet packages or linking to other libraries? Or linking to other parts of the build process?

    Assertion A unit test is a test that can be run as part of a build

    That’s very descriptive! It helps define the kinds of things that shouldn’t be in a unit test: If a test will fail under a build on a dev machine – any dev machine, then it isn’t a unit test. Does the dev machine need to have a network connection? Then the test will fail if it doesn’t, and shouldn’t be in a unit test. Does the test depend on any setup that isn’t part of setting up a build machine? Then also, no.

    And yet, there are plenty of tests that could be run as part of a build that really spill beyond the bounds of “unit test” well into “integration test” territory.

    But still, this is useful: unit tests shouldn’t take so long as to make running them as part of a build unreasonable. Unit tests shouldn’t require anything that isn’t part of the build.

    We have so many different kinds of tests – smoke test, integration test, component test, functional test. I don’t think any of these terms really has as definitive a meaning as we think it does. So how about we use names that imply more about what the test is – a build test would be a test that happens as part of a build. A class test would be a test that exercises the capabilities of a class – and there’s no fudging over what class means. A library test would be a suite that exercises all the exposed functions of a library. An endpoint test would be a test that covers a particular web endpoint. A cloud test would be a test that can be run when the product is deployed in the cloud. A local test would be a test that can be run when only a local machine is assumed to be available.

    Could there be a local library build test? You bet there could. And you already know more precisely what it is than you know about what a “unit test” is.

    How does your team classify tests? I’ll bet having more precise classifications for your tests will help your team work together.

  • Great interview with former FBI special agent Asha Rangappa about all the trouble Trump and his circle of mobsters have gotten into on the Josh Marshall podcast: talkingpointsmemo.com/podcasts/…

  • This is the closest I’ll ever come to being a contributor on Last Week Tonight!

  • Matthew 26:11

    The poor you will always have with you...its the rich SOBs you gotta watch out for.

  • I hate TSA PreCheck

    Its a sign of crappy government: [bigboxofpaints.wordpress.com/2017/12/2...](https://bigboxofpaints.wordpress.com/2017/12/23/i-hate-tsa-precheck/)

  • A Swift Nugget: the generic meh comparator

    A swift nugget: 

    I had the occasion where I wanted to create a generic collection of things with the initializer taking a comparison operator.  But then I also wanted to have the default behavior be “meh”, and return that the items were always equal.  This is what I came up with:

     

    struct GenericCollection<T> {

        

        var values: [T]

        typealias tComparator = (T?,T?) -> ComparisonResult

        var precendenceFunction: tComparator

        

        static func meh(_:T?, _:T?) -> ComparisonResult {

            return .orderedSame

        }

        

        init(comparator: @escaping tComparator = GenericCollection<T>.meh) {

            precendenceFunction = comparator

            values = []

        }

     }

     

    I went through a number of iterations with something like this:

     

    func meh<U> (_:U?,_:U?) -> ComparisonResult {

        return .orderedSame

    }

     

    struct GenericCollection<T> {

        

        var values: [T]

        typealias tComparator = (T?,T?) -> ComparisonResult

        var precendenceFunction: tComparator

        

        init(comparator: @escaping tComparator = meh<T>) {

            precendenceFunction = comparator

            values = []

        }

     }

     

    but couldn’t avoid a "Cannot explicitly specialize a generic function” error.  Somehow I wish a generic meh<U> strategy would work — if anyone knows how to do that, let me know!

  • “HomePods” is an anagram of “Dope Ohms” #WWDC

  • Minimum wage laws are ‘anti-dumping’ provisions for labor.

  • “It takes courage not to be discouraged.” - Benjamin Ferencz

  • Well this is interesting:  “Modern version of Frontier"

  • Just read the Stephens column in New York Times.  I don’t want to cancel my totally useless subscription, so I’m getting a puppy.

  • Day one of a new era. Feels great!

subscribe via RSS