Skip to main content
16 events
when toggle format what by license comment
Nov 19, 2016 at 16:49 comment added Fabio In TDD merge must be invented only on "refactoring" stage. If you see that merge method can be introduced for passing test of mergesort you first make your tests pass without merge method. Then refactor your implementation by introducing merge method.
Nov 9, 2016 at 21:08 history tweeted twitter.com/StackSoftEng/status/796459415637528577
Nov 9, 2016 at 20:20 comment added Doc Brown Heavily recommended: geekswithblogs.net/theArchitectsNapkin/archive/2014/02/10/…
Nov 9, 2016 at 20:04 comment added Ray Toal Correct. I am not looking to discover. I wanted to see if doing TDD following the three rules would give me 100% test coverage and wanted to stay disciplined in not writing any code that wasn't to make a failing test pass, etc. I ran into a bit of a conundrum when trying to write this thing top-down, because jumping out to implement a sub-function while a failing unit test was hanging didn't fit the methodology. I am trying to understand whether this is a "weakness" or whether there are better approaches.
Nov 9, 2016 at 19:56 comment added Andres F. In this case, like @RobertHarvey said, mergesort is known so you shouldn't pretend you are not aware of it. But do know TDD is not particularly well-suited to algorithm discovery. If you were trying to actually derive a new algorithm, TDD is not the best way to go about it.
Nov 9, 2016 at 19:54 vote accept Ray Toal
Nov 9, 2016 at 19:53 history edited Ray Toal CC BY-SA 3.0
edited body
Nov 9, 2016 at 19:46 answer added kdgregory timeline score: 13
Nov 9, 2016 at 19:38 comment added Ray Toal Makes sense, got it
Nov 9, 2016 at 19:36 comment added Robert Harvey Design doesn't grow itself from unit tests alone; if you're expecting a mergesort design to emerge naturally from red-green-refactor, that won't happen unless you guide the process based on your existing knowledge of mergesort.
Nov 9, 2016 at 19:30 comment added Robert Harvey ...Subsequent unit tests would gradually dig deeper into the actual mechanics of a mergesort. If you're looking for the "right" way to do this, there isn't one, other than to be accurate about your mapping of the mergesort algorithm to a series of unit tests; i.e. they should reflect what a mergesort actually does.
Nov 9, 2016 at 19:30 comment added Robert Harvey Part of the goal of TDD is to help you create a software design. Part of that design process is discovering what is needed to produce the desired result. In the case of mergesort, since it's already a very well-defined algorithm, this discovery process is not required, and it then becomes a matter of mapping what you already know to be the design to a series of unit tests. Presumably, your top level test asserts that your method under test accepts an unsorted collection and returns a sorted one...
Nov 9, 2016 at 19:26 comment added Ray Toal So you suggest that either (1) writing merge, the entire complex 6-10 line function, is just a part of making the last mergesort test pass? Or if I wanted to use TDD on it, I do it off to the side? Did I get that right? Is it a pitch for option 1? Also, I can easily write a test set, but I'm trying to follow the three rules. This is part of an experiment to see how granular TDD can be in certain cases.
Nov 9, 2016 at 19:20 history edited Ray Toal CC BY-SA 3.0
added 1 character in body
Nov 9, 2016 at 19:20 comment added Robert Harvey mergesort isn't a use case; it is an implementation of a use case (the actual use case being sorting), and a very well-defined one at that. You should be able to take the definition of mergesort and produce a very well-defined and specific set of unit tests from which you can derive your actual implementation.
Nov 9, 2016 at 19:19 history asked Ray Toal CC BY-SA 3.0