Timeline for Is it sufficient to use acceptance and integration tests instead of unit test?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2014 at 15:55 | comment | added | Robbie Dee | Well indeed. There has been a flourishing market for automated 3rd party tools that exist outside the development sphere for some considerable time. | |
| Jan 13, 2014 at 14:42 | comment | added | Jan Hudec | Automating testing and unit testing are completely orthogonal matter. Any self-respecting project will have automated integration and functional testing. Granted, you don't often see manual unit tests, but they can exist (basically manual unit test is a testing utility for some specific functionality). | |
| Jan 13, 2014 at 14:33 | history | edited | Robbie Dee | CC BY-SA 3.0 | edited body |
| Jan 13, 2014 at 13:18 | comment | added | Robbie Dee | The example I was thinking of in the last paragraph is where say, a library was used exclusively by a single application but there was then a business requirement to make this a general purpose library. In this case it might better serve you to have at least some unit testing rather than write new integration/behaviour tests for every system you attach to the library. | |
| Jan 13, 2014 at 11:01 | comment | added | twilker | I write my tests upfront and I write enough tests to cover most of the errors. As for bugs which surfaces later. This sounds to me, that a requirement has changed or a new requirement comes into play. Than the integration/behavior tests need to be changed, added. If then a bug is shown in an old requirement my test for this will show it. As for the automation. all my tests run all the time. | |
| Jan 13, 2014 at 10:56 | history | answered | Robbie Dee | CC BY-SA 3.0 |