Timeline for Concurrent, identical instances as an integration test
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2024 at 22:16 | comment | added | candied_orange | @nicholaswmin A pattern having a name doesn’t make it a good thing. If someone went to the trouble of making their tests deterministic and the unit functional it’d be nice if there was an easy way to say that before I screw it up. | |
| Oct 25, 2024 at 22:13 | comment | added | candied_orange | Let us continue this discussion in chat. | |
| Oct 25, 2024 at 17:56 | comment | added | nicholaswmin | The sentiment behind it is something that you might or might not have experienced yourself; I think it's common. There's a phase that (some) of software engineers go through in their careers, if they care about their work - and that's a phase of being incessitanglt theoretic and scientififc about stuff they shouldnt be, like stupidly applying design patterns for no reason. It is a very miserable and inflexible phase and one you feel nice exiting from. I don't want the same to happen about testing, because that's my second "big revelation" in this profession, for lack of a better word | |
| Oct 25, 2024 at 17:50 | comment | added | candied_orange | As for your credit, I respect anyone trying to make sense of this mess. The reason IO is a boundary is because once that involved you've lost control of side effects. The subtle problem here is once that happens it doesn't tell you. Everything will seem fine, then you commit of a Friday and a test decides to behave differently right when you want to go home. | |
| Oct 25, 2024 at 17:50 | comment | added | nicholaswmin | Yes, I see your point. I mean, I do the same as stated in the OP but I just don't see it as it's exclusive and definitive characteristic. Then again thats not what you said, you only said it's the outer limit. It's Friday and I'll leave it at " i see... ok" | |
| Oct 25, 2024 at 17:44 | comment | added | candied_orange | @nicholaswmin A Set of Unit Testing Rules - Michael Feathers lists 5 rules. The first 3: database, network, and file system are IO. The other 2 are important as well but hard to point at in an architectural chart. | |
| Oct 25, 2024 at 17:39 | comment | added | nicholaswmin | > @nicholaswmin where is this debate raging? Right here. Exhibit A. > What I've experienced is there are those who have a disciplined opinion of what a unit test is and those who call it a unit test because they run it with a tool with unit in its name, like jUnit. You're not giving me the credit I deserve; I'm a fanatic of unit-testing and I am aware of every single detail you're mentioned. I wholehearteadly agree with them but I don't see them as relevant to the assertion: The outer limit for a unit test is IO. It's the "unit" that is the outer limit. | |
| Oct 25, 2024 at 17:34 | comment | added | candied_orange | @nicholaswmin where is this debate raging? Please point me to it. What I've experienced is there are those who have a disciplined opinion of what a unit test is and those who call it a unit test because they run it with a tool with unit in its name, like jUnit. True unit tests require a functional core. Almost every code base has some code that qualifies. To make good use of unit tests almost every code base needs stuff moved around to make a lot of the code qualify. You don't get this for free. | |
| Oct 25, 2024 at 17:25 | comment | added | nicholaswmin | I most certainly agree with you on all points. Where I disagree on categorically is the insinuation that a unit-test is defined by the process boundaries. That would settle a debate going on for quite some time, rapidly. My understanding is that it's defined by the "unit" ... whatever that means to anyone. I was complaining about your reduction of it's definition to a very narrow, technical consideration. ButI s that what you really meant, or are we misunderstanding you and pointlessly arguing? | |
| Oct 25, 2024 at 17:21 | comment | added | candied_orange | @nicholaswmin Well thank you. I certainly don't want to interfere with you achieving clarity. I hope you realize I'm not saying you can't write whatever automated tests you find useful. I'm only saying when you call them unit tests there is an expectation that they are deterministic. A fancy way to say they always do the same thing. Ensuring that comes with requirements. I'm not arguing against integration tests. I just want to call a spade a spade. I don't understand how that is harming your clarity. | |
| Oct 25, 2024 at 17:10 | comment | added | nicholaswmin | Although admittedly I am a fan of this candied orange on this site, I do not like your definition of a unit test at all. The main reason is that they negate the primary benefit I get by each unit test which is the clarification of some aspect of my program, in my own head. | |
| Sep 2, 2024 at 6:40 | comment | added | Flater | @candied_orange: Unless you believe that "check my answer history to find out the answer to your question" is an acceptable format for StackExchange; yes you should be answering the question at hand with the information needed to answer it. As to the link you added in your answer, its content amounts to "A test is not a unit test if [reasons]", which should not be logically inverted into "therefore everything else is invariably a unit test". This is faulty reasoning and the precise issue with this answer. It implies something that you know not to be true but can't be bothered writing. | |
| Sep 2, 2024 at 2:46 | comment | added | Flater | "When I say you can’t do X that doesn’t mean I said you can do Y" is not an accurate summary of the answer stating "If you're keeping them in the local memory space [..] then calling this a unit test is fine". The part of the answer quoted here effectively states that being in-memory outright qualifies a test to be considered to be a unit test, without further modifiers added, which is simply not correct. It's correct that a test that crosses the IO boundary is definitely not a unit test. It's not correct that a test that doesn't cross the IO boundary therefore invariably is a unit test. | |
| Sep 2, 2024 at 2:42 | comment | added | Flater | @candied_orange: If the question is "is this [single-runtime] test a unit test?" (which it is), and your answer explains how it's not a unit test when it goes across IO boundaries and it's fine to call it a unit test if it's in-memory (which it does); then the logical inference is that you're addressing the IO boundary as the boundary of when it is/isn't a unit test. This is why I called your answer imprecise instead of wrong, because I think you're aware that IO is not the only boundary for unit tests, but the answer is not addressing those points and appears to be implying otherwise. | |
| Sep 2, 2024 at 0:03 | comment | added | Flater | This answer is imprecise. While the IO boundary is definitely a boundary for a unit test, that doesn't mean it's the only boundary. There's nothing wrong with defining unit boundaries more granularly than on the IO boundaries of the application. Similarly, a test run within the IO boundaries of an application can still be considered an integration test. Effectively, it's an integration test when two or more (individually cohesive) units are being tested at the same time. | |
| Sep 1, 2024 at 21:18 | comment | added | candied_orange | @DocBrown there are certainly more requirements. But being a single class is not one of them. | |
| Sep 1, 2024 at 16:19 | comment | added | Doc Brown | A test which requires to include external I/O is surely not a unit test, but just because a test does not require I/O, I would not conclude it is a unit test. | |
| Aug 30, 2024 at 15:27 | history | answered | candied_orange | CC BY-SA 4.0 |