> Testing third-party code is often well within the purview of first-party *inte...

randomdata · on Dec 20, 2023

Assuming 'integration test' is being said under a common definition, and not one being made up on the spot, the integration points don't expose third-party code in way that you could even begin to explicitly test them. it is fundamentally impossible. If it were possible, you would have no reason to be writing software – the third-party already did the work for you.

OJFord · on Dec 21, 2023

I'm not making up anything on the spot, it's massively overloaded/differently used by different people.

At it's 'lowest' level it's the integration of multiple units: basically anything that covers multiple functions.

The line's also drawn (with the above still being a 'unit test') at the API: so if you exercise your handler code like `views.Widget.post(...)` then it's unit; if you do `requests.post("/api/widget")` it's integration.

And at it's 'highest' level it's used to mean system or end to end testing (depending which of those you you use to mean automated testing of a deployed system).

randomdata · on Dec 21, 2023

> At it's 'lowest' level it's the integration of multiple units: basically anything that covers multiple functions.

So, testing...?

   test_unit_1 {
      assert(foo())
   }

   test_unit_2 {
      assert(bar())
   }

That's not a use of 'integration' that anyone would ever find useful. If they do, they must not be software developers. 'Integration' adds nothing. But, if this is the definition you have made up on the spot, then, yes, you could use this to explicitly test a third-party library. It is no surprise that you can explicitly test a third-party library using testing.

   test_unit_1 {
      assert(third_party_library.foo())
   }

But even then, it is not clear why you would meld that into your application's project and not its own project? It has absolutely nothing to do with your first-party application. Logically, that kind of test is best kept in the third-party library's own project.

--

Perhaps you misspoke and meant a single unit that covers multiple functions?

   test_unit_1 {
      write()     
      assert(read())
   }

But that is also just testing... As soon as you have internal mutable state (every program that does something; not even the FP diehards are able to completely avoid internal mutable state), you are always going to have to call at least two functions – one to mutate the state, another to observe the state afterwards. Here too, 'integration' adds nothing. There is no practical situation where you would ever communicate this as being distinct from the above. If this is it, it is also clearly made up on the spot.

--

The remaining two I guess say something, albeit flimsily, but obviously do not allow explicit testing of third-party code. Take the second case, since it provides some concrete code. Show us how you would update that code to explicitly test some third-party library. Remember that you said it calls "your handler code". I will wait.

OJFord · on Dec 21, 2023

Regarding the first, yes I thought obviously I meant per single unit resp. integration test. And 'covers' meaning what is actually under test.

So:

    test_1 {
        result = waz()
        assert result == 42
    }

is an 'integration test' vs. a 'unit test', according to people using the first definition, exactly when `waz` calls other functions vs. is somewhat pure.

I do not consider that I 'misspoke', but I hope that clarifies it for you.

> The remaining two I guess say something, albeit flimsily, but obviously do not allow explicit testing of third-party code. Take the second case, since it provides some concrete code. Show us how you would update that code to explicitly test some third-party library. Remember that you said it calls "your handler code". I will wait.

Don't wait, because I've no interest in continuing this.

randomdata · on Dec 22, 2023

> is an 'integration test' vs. a 'unit test'

I don't get it. There isn't a contention between the two. The definition of unit test is a test that is independent of other tests. That would include any integration test that exists independent of other tests.

Frankly, as far as I can see all tests written in any modern codebase are unit tests. It is not the 1970s anymore. We learned our lessons. Realistically, while the 'unit test' branding may have helped us learn those lessons, it doesn't add anything today. In the modern lexicon, 'test' already implies 'unit test'. They are one in the same.

> I hope that clarifies it for you.

Nope. I honestly have absolutely no idea what you are trying to say there. Sorry.

> Don't wait, because I've no interest in continuing this.

I expected. I wouldn't have interest in trying to show something that is impossible either.