Timeline for Wouldn't it be beneficial to write tests during code review?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 13, 2016 at 11:00 | audit | First posts | |||
| May 13, 2016 at 11:00 | |||||
| May 10, 2016 at 8:33 | comment | added | Robbie Dee | @jpmc26 You've missed the point slightly I feel - I wasn't passing comment on how we operate here or anywhere else, rather positing the possibility. The developer is best placed to identify possible shortcomings in their code - hence the accepted wisdom of TDD (specifically, the timely part of FIRST principles). | |
| May 10, 2016 at 8:22 | comment | added | jpmc26 | @RobbieDee If the receiver of blame actually matters, you have an unhealthy development environment. This is far worse than missing a few tests that would have been useful. | |
| May 10, 2016 at 8:13 | comment | added | Robbie Dee | @jpmc26 Yes, but if the dev writes the tests then they are at fault if an issue is identified when it goes live. If the code reviewer writes the tests and this is missed, they can simply blame the developer. There is more of an incentive for the developer to get it right than a code reviewer who is writing the tests as an ancillary task. | |
| May 10, 2016 at 7:25 | comment | added | Jan Hudec | It also depends on when the review happens. If it happens the “traditional” way (i.e. at the end of project, often pushed after the actual delivery—been there), it's way too late. If it happens the “modern” way before integration of each task, the gap is not big. However, I suspect if @Sok can't push TDD, they might not be able to push review before integration either. | |
| May 10, 2016 at 2:39 | comment | added | jpmc26 | "as can the diligence" Writing tests up front suffers from this particular problem as well. | |
| May 9, 2016 at 18:56 | comment | added | ArTs | In fact I would say it, distracted from the code review process and the code would affect the testing process, which is not what you want, taking away the key advantage of having a separate tester and coder. | |
| May 9, 2016 at 18:47 | comment | added | ArTs | The problem is called "Conformational Bias". | |
| May 9, 2016 at 16:07 | comment | added | Robbie Dee | I think perhaps as well as someone else writing the tests, these could be run against development code whilst development is in progress. The developers in question would need to be on the same page as to where the code is at otherwise the developer writing the code could be constantly fire-fighting failed tests rather than actually getting the thing working. | |
| May 9, 2016 at 15:57 | comment | added | Sok Pomaranczowy | Great answer. But what if we won't do TDD because the people don't want to and I have no leverage over them but we need to make sure that the result we get are not false positives because an error skewed our results? The main risk is that people might rush to implement something without proper understanding, write tests with that improper understanding in mind making tests pass but ultimately producing wrong code. Maybe pair programming would solve the matter? But then again it is easy to force ones understanding of something on someone. | |
| May 9, 2016 at 15:42 | history | edited | Robbie Dee | CC BY-SA 3.0 | added 9 characters in body |
| May 9, 2016 at 15:35 | history | answered | Robbie Dee | CC BY-SA 3.0 |