Code Monkey home page Code Monkey logo

discovery-testing's People

Contributors

searls avatar

Watchers

 avatar  avatar  avatar

discovery-testing's Issues

Some thoughts on the screen cast

I want to share a couple of thoughts on the screencast. Justin asked me to use GitHub issues instead of email so other people can see it. Here it goes.

First of all, I use mocks and I use a similar style of TDD. This is not criticism – I often use the GOOS approach. I just want to discuss some fine points.

  1. In the screencast, it does not seem that the tests contributed to the design. You had already decided how to break it down (generate, save, describe) before you started writing tests. The issues you mentioned (e.g. anxiety) could be addressed by doing that "design" work up front and not writing tests with pretty much the same results. At worst, you can create empty stubs for the functions and still reap the same benefits (deciding on the names, having some file structure in place).
  2. When finished, it is not obvious what the benefit of the test is. It does not provide much (or anything) in terms of regression. It is also considerably more complex than the code it tests (a simple composition of three functions) and it is not evident why that complexity (or even typing) is worth it.

That being said, I think I say that because of the example – it is quite simple and it does not illustrate the pragmatic benefit of this approach. I think a different example will do better – maybe one that has to integrate with a couple of messy collaborators or one where having those tests helps us spot introducing a bad design decision.

By the way, I don't see much value in test-driving code with isolated collaborators (think Rails controllers). I still do it anyway, since I get value afterwards. Whenever I add code to the controller, I find that the existing tests help me think about the effect of the addition. Fox example, it helps me spot if I introduce a needless collaborator or if I introduce too much coupling. Otherwise I tend to get sloppy in those bits since they are small and understandable enough.

Finally, I really liked the idea about rewriting code vs. reusing. I'm trying to think about a good formulation that doesn't seem too outrageous.

Hope this is useful :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.