Timeline for Is it sufficient to use acceptance and integration tests instead of unit test?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 29, 2023 at 6:53 | comment | added | Tristan | Could u give me your lights on a similar but more detailed question about the "pyramid of tests" principle : softwareengineering.stackexchange.com/questions/445771/… | |
| Nov 28, 2018 at 16:43 | comment | added | Ryall | Truly the best answer IMO. It's rare that someone in the programming world doesn't try and push their own opinion as gospel (especially in TDD) and this answer simply outlines the pros and cons of only testing at a high level. Everyone's situation is different and often requires different strategies to testing. Well done @dietbuddha | |
| Oct 13, 2017 at 0:05 | comment | added | iteratingself | @starmandeluxe They are indeed not mutually exclusive. Rather it is a question of the value you want to derive from testing. I would unit test anywhere where the value exceeded the development/support cost of writing the unit tests. ex. I would certainly unit test the compounding interest function in a financial application. | |
| Sep 20, 2017 at 6:17 | comment | added | starmandeluxe | Can you give your input on the (IMO best) option of doing BOTH integration and unit testing vs the argument of only doing integration testing? Your answer here is good, but seems to frame these things as mutually-exclusive, which I do not believe they are. | |
| Apr 16, 2015 at 21:58 | comment | added | Rogério | "Unit tests help enforce IOC"?!? I am sure you meant DI there instead of IoC, but anyway, why would someone want to enforce the use of DI? Personally, I find that in practice DI leads to non-objects (procedural-style programming). | |
| Jan 14, 2014 at 15:24 | history | edited | iteratingself | CC BY-SA 3.0 | deleted 7 characters in body |
| Jan 14, 2014 at 10:31 | comment | added | twilker | Good point for pinpointing the specific problem. If I have a huge requirement I write acceptance tests which test the whole system and than writing tests which tests sub tasks of certain components of the system to achieve the requirement. With this I can pinpoint in most cases the component where the defect lies in. | |
| Jan 13, 2014 at 16:03 | comment | added | Robbie Dee | Excellent point. It is all too easy to become a little space cadetish about testing and write hundreds of cases to get a warm glow of satisfaction when it "passes" with flying colours. Simply put: if your software doesn't do what it needs to do from the USER'S point of view, you have failed the first and most important test. | |
| Jan 13, 2014 at 15:50 | history | answered | iteratingself | CC BY-SA 3.0 |