Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There's a reason why TDD is strongly linked with XP and Agile philosophies. It drives us to small units of testable code. So concepts like TheSimplestThingWhichCouldPossiblyWork or the Single Responsibility Principle fall out of a test driven approach.</p> <p>That clearly hasn't happened in your scenario. You fixated on the array of numbers, rather than the FizzBuzz bit (the clue really is in the question). </p> <p>Obviously you're in a totally artificial situation and it's hard to fake TDD. But I would expect "real" TDD code to have exposed the translation methods. Something this:</p> <pre><code>@Test public void testOtherNumber() { String result = FizzBuzz.translateNumber(23); assertEquals("23", result); } @Test public void testMultipleOfThree() { String result = FizzBuzz.translateNumber(3); assertEquals("Fizz", result); } @Test public void testMultipleOfFive() { String result = FizzBuzz.translateNumber(25); assertEquals("Buzz", result); } @Test public void testMultipleOfFifteen() { String result = FizzBuzz.translateNumber(45); assertEquals("FizzBuzz", result); } </code></pre> <p>The point being that each of those produces a clear result and is easy to start with a failing test. </p> <p>Having done the FizzBuzz bit it is a cinch to do the array stuff. The key point about that is to avoid the hardcoding. Initially we might not want a full implementation: it would be sufficient to generate a relative handful of number of elements, say 15. This has the advantage of producing a better design. After all, if the interviewer came back and said "Actually I want an array of 121 elements", how much of your code would you have to change? How many tests?</p> <hr> <p>One of the challenges of TDD is knowing where to start. Gojko Adzic wrote a thought-provoking piece on this, describing <a href="http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/" rel="nofollow">a Coding Dojo implementing a game of Go</a>. </p> <hr> <blockquote> <p>"Is there a chance exposing my translation methods would have marked against me on the grounds of encapsulation later on?"</p> </blockquote> <p>One of the most hotly debated topic in TDD. Possible answers are:</p> <ol> <li>keep the methods private and embed the unit tests in the class.</li> <li>write the tests against public methods, then make the methods private one the tests pass, and refactor the tests.</li> <li>variation on the above: use conditional compilation (or similar) to expose or hide the methods.</li> <li>just keep them public</li> </ol> <p>There are no right answers, and often it will depend upon specific requirements or personal whim. For instance, while FizzBuzz itself is trivial we are quite often required to write code which takes data, appplies a business rule and returns a validation outcome. Sometimes the rule needs to be applied to a single item of data, sometimes against entire record sets and sometimes against either. </p> <p>So an API which exposes both methods is not necessarily wrong. And certainly in an interview situation it gives you the opportunity to discuss the nuances of API design, which is a good topic of conversation.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload