- High horse - 3 Updates
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 01:34PM -0400 On 06/04/2018 12:16 PM, Mr Flibble wrote: ... > functions without the need to maintain a class invariant; these other > private member functions may indeed have no testable consequences unless > taken together with the other private member fun So perform a test that takes them together with the other private member functions (which must also, of course, be invoked indirectly). What's the problem? The important thing isn't how the code is subdivided into individual functions, whether public or private. The important thing is what the code actually does. If you can stub out a private member function without producing any testable failure to meet requirements, you don't need that function to meet requirements - it's inherently and by definition that simple. For example, consider a private function which is intended to meet the requirement that it cause a visit to the user by the Invisible Pink Unicorn <https://en.wikipedia.org/wiki/Invisible_Pink_Unicorn>. By Her very nature, it's inherently impossible to prove whether or not She has visited, so there would be no testable consequences of stubbing out that function. But for precisely the same reason, there's no problem with delivering that code with the function still stubbed out. |
| cross@spitfire.i.gajendra.net (Dan Cross): Jun 04 10:07PM >There are actual academic studies among programmers doing comparable >work with and without TDD. The ones using TDD got to completeness >first faster on average than those that didn't use TDD. ...and there are conflicting reports showing that TDD leads to slower task completion, albeit with fewer defects (Nagapan et al). But note that I said *testing*, not *TDD*: the two are not synonymous. - Dan C. |
| "Ross A. Finlayson" <ross.finlayson@gmail.com>: Jun 04 03:11PM -0700 On Friday, June 1, 2018 at 11:29:00 PM UTC-7, Paavo Helde wrote: > The same can be said for any tool or methodology of course, but it looks > like TDD is especially prone to misunderstandings and misuse for some > reason (it cannot beat "agile" of course ;-) TDD? Only as strong as the formal model (and the space of its inputs), usually of which there is none. TDD and coverage is a nice safety net for coders who can't be bothered to read most of the code. It's difficult to achieve 100% coverage because most of the interactions (of the "units" together) isn't "designed for test". Thus it's nice sometimes when library vendors surface mocks. Tests are _part_ of coverage then often and usually for runtime coverage. Of course having tests saves many production systems from immature changes. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment