• louis vuitton outlet
  • nike air max
  • ray ban uk
  • oakley sunglasses outlet
  • cheap jordan shoes
  • toms outlet
  • Cheap Oakleys Sunglasses
  • fifa coins
  • ray ban
  • cheap uggs
  • ray ban uk
  • nike air max
  • ray ban outlet
  • burberry uk
  • fut coins
  • fut 14 coins
  • fut coins
  • Christian Louboutin Outlet
  • michael kors outlet
  • coach outlet
  • louis vuitton outlet
  • fifa coins
  • ray ban
  • Custom iphone cases
  • nike
  • monster beats
  • nike outlet
  • Christian Louboutin Outlet
  • burberry outlet
  • coach outlet
  • iphone cases
  • LV
  • new balance
  • Effective Tests: How Faking It Can Help You

    Effective Tests: How Faking It Can Help You

    On March 29, 2011, in Uncategorized, by derekgreer
    This entry is part 5 of 17 in the series Effective Tests

    In part 4 of our series, I presented a Test-Driven Development primer before beginning our exercise.  One of the techniques I’d like to discuss a little further before we continue is the TDD practice of using fake implementations as a strategy for getting a test to pass. 

    While not discounting the benefits of using the Obvious Implementation first when a clear and fast implementation can be achieved, the recommendation to “Fake It (Until You Make It)” participates in several helpful strategies, each with their own unique benefits:

     

    Going Green Fast

    Faking it serves as one of the strategies for passing the test quickly. This has several benefits:

    One, it provides rapid feedback that your test will pass when the expected behavior is met. This can be thought of as a sort of counterpart to "failing for the right reason".

    Second, it has psychological benefits for some, which can aid in stress reduction through taking small steps, receiving positive feedback, and providing momentum.

    Third, it facilitates a "safety net" which can be used to provide rapid feedback if you go off course during a refactoring effort.

     

    Keeping Things Simple

    Faking it serves as one of the strategies for writing maintainable software.

    Ultimately, we want software that works through the simplest means possible. The "Fake It" strategy, coupled with Refactoring (i.e. eliminating duplication) or Triangulation (writing more tests to prove the need for further generalization), leads to an additive approach to arriving at a solution that accommodates the needs of the specifications in a maintainable way.  Faking It + Refactoring|Triangulation is a disciplined formula for achieving emergent design.

     

    Finding Your Way

    Faking it serves as a strategy for reducing mental blocks. 

    As the ultimate manifestation of “Do the simplest thing that could possibly work", quickly seeing how the test can be made to pass tends to shine a bit of light on what the next step should be. Rather than sitting there wondering how to implement a particular solution, faking it and then turning your attention to the task of eliminating duplication or triangulating the behavior will push you in the right direction.

     

    Identifying Gaps

    Faking it serves as a strategy for revealing shortcomings in the existing specifications.

    Seeing first hand how easy it is to make your tests pass can help highlight how an implementation might be modified in the future without breaking the existing specifications.  Part of the recommended strategy for keeping your code maintainable is to remove unused generalization.  Generalization  which eliminates duplication is needed, but your implementation may include generalization for which the driving need isn’t particularly clear.  Using a fake implementation can help uncover behavior you believe should be explicitly specified, but isn’t required by the current implementation.  Faking it can lead to such questions as: “If I can make it pass by doing anything that produces this value, what might prevent someone from altering what I’m thinking of doing to eliminate this duplication?

     

    Conditioning

    Lastly, faking it helps to condition you to seeing the simplest path first.  When you frequently jump to the complex, robust, flexible solution, you’ll tend to condition yourself to think that way when approaching problems.  When you frequently do simple things, you’ll tend to condition yourself to seeing the possible simplicity in the solution provided.

     

    Conclusion

    While we should feel free to use an Obvious Implementation when present, The Test-Driven Development strategy of “Fake It (Until You Make It)” can play a part in several overlapping strategies which help us to write working, maintainable software that matters.

    Series NavigationEffective Tests: A Test-First Example – Part 1Effective Tests: A Test-First Example – Part 2
    Tagged with:  
    • http://www.truewill.net/myblog/index.php Bill Sorensen

      Nice post! Thank you!

      I’m still a little confused by the section on “Identifying Gaps” though.

    • http://aspiringcraftsman.com derekgreer

      Thanks for the feedback. I would need more to go on to know how I should elaborate specifically, but my general premise in the “Identifying Gaps” section is that keepig your focus on the outcome rather than the journey will help you better recognize where the measurement of the outcome is insufficient.