Timeline for Choosing names for integration tests
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2012 at 1:53 | history | edited | Turnkey | CC BY-SA 3.0 | Reworded advice on one assert, based on feedback from Andrew |
| May 23, 2012 at 1:47 | comment | added | Turnkey | @Andrew, I didn't say it was a hard rule, but a watching the number of asserts could help with guideline of testing a concept of the feature not necessarily one per method. Keeping them somewhat limited in scope helps identify where the problems are when they fail. But I'll give you that it is not great to say one assert, and I'll edit that out, thanks. | |
| May 22, 2012 at 19:00 | comment | added | Jeremy | Why do you believe "one feature" generally equates to "one assert"? It seems you would want to assert that the system is in the state you expect it to be in, which can be any number of asserts. But I digress because the question is about naming, not how to write an integration test. | |
| May 22, 2012 at 18:11 | history | answered | Turnkey | CC BY-SA 3.0 |