Timeline for Is it right to skip unit testing and go straight writing integration tests if there's no point of testing the unit in isolation?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2017 at 11:19 | comment | added | Ewan | no. in theory you can expose the exact error either way. Indeed there is a strong argument to run any unit test as an integration or end to end test. In practice though this is hard, expensive and time consuming | |
| May 3, 2017 at 11:08 | comment | added | Xegara | Does not that imply that these different types of tests actually "complement" each other in ways that they address certain problems that other types of test fail to address (e.g. units may passed their unit tests but fail their integration tests due to external reasons and integration tests only tell there is a problem but only the unit test can directly pinpoint the exact piece of logic that causes the error)? | |
| May 3, 2017 at 10:59 | comment | added | Ewan | surely I have answered that specific case? your integration tests fail for reasons other than incorrect code. so if you are working on the train, or the environment is down, or your dont know the ip address etc, you cant run them. plus the other listed disadvantages | |
| May 3, 2017 at 10:55 | comment | added | Xegara | I think I can distinguish the difference between the three tests. But what I'm after is the reason why we should write all of the unit test, integration test and e2e test to test one functionality (e.g. authentication module) | |
| May 3, 2017 at 10:47 | comment | added | Ewan | I think you are too caught up in what to call the tests, rather than what the thing you need to verify works is. Write test for all the things. what you call them is academic | |
| May 3, 2017 at 10:44 | comment | added | Xegara | Tbh, I am confused as I still cannot see the "why" reason of writing unit, integration and e2e tests if it were not to complement each other since their approach to testing the same modules are different | |
| May 3, 2017 at 10:36 | comment | added | Ewan | for instance If you have a simple repository which works with a particular db. Unit tests where you mock the DB have limited value because the majority of errors are due to generating and running sql. | |
| May 3, 2017 at 10:30 | vote | accept | Xegara | ||
| May 3, 2017 at 10:29 | comment | added | Ewan | I think i would put it the other way around. You have many things to test, some are easier to test with integration and some with unit tests. Its possible that there are simple cases where all the things you need to test fall into one category, but unusual. | |
| May 3, 2017 at 9:29 | comment | added | Xegara | So the reason why we should write both unit and integration tests is because we're testing for different errors? | |
| May 3, 2017 at 8:04 | history | edited | Ewan | CC BY-SA 3.0 | added 887 characters in body |
| May 3, 2017 at 8:01 | comment | added | Ewan | ive edited my question to provide an example of what I mean. yes, code duplication should be avoided where possible. I'm not sure i would say layers or compliment, but yes you have to test that a function works both with a mocked setup of known in memory data AND that it works with a real datasource in a deployed envrionment. Although the code may be identical the test is testing for different errors | |
| May 3, 2017 at 7:57 | history | edited | Ewan | CC BY-SA 3.0 | added 887 characters in body |
| May 3, 2017 at 7:44 | comment | added | Xegara | Let me rephrase my poorly written question: are the different layers of testing meant to complement each other rather than minding their own business such that it is not considered a bad practice to write and test the same function across the different layers of tests? | |
| May 3, 2017 at 7:39 | comment | added | Ewan | hmmm, a lot of double negatives in that question. I think you need both unit and integration tests. (some of) those tests might test the same function. but you can avoid literal code duplication through data driven tests or other methods | |
| May 3, 2017 at 7:35 | comment | added | Xegara | Are you saying that the notion of not writing possibly duplicating test cases across the unit, integration and e2e test is wrong because these layers of tests are meant to complement each other rather than minding their own business? | |
| May 3, 2017 at 5:47 | history | answered | Ewan | CC BY-SA 3.0 |