4 ms·

> At it's 'lowest' level it's the integration of multiple units: basically anything that covers multiple functions. So, testing...? test_unit_1 { ass

> 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 3y ago
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 3y ago
  > 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.

OJFord 3y ago

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 3y ago
> 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.