Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One thing which surprises a lot of developers after they've been doing testing for a while is discovering that testing doesn't just make their code more reliable, it makes them a better programmer. Your functions tend to do less, but do it better. You learn to decouple things. You learn that your function with 13 arguments might be poorly designed. You learn how to write less code and get more done. You learn how to refactor safely. You design better APIs. You learn first-hand the pain of violating the Liskov Substitution Principle. As a result, a talk explaining the evolution of a TDD programmer might be worthwhile.

    Testing best practices might also be good. Lots of people talk about how to test, but they ignore the best practices while writing tests. There's also the curious thing that best practices while writing tests are subtly different. For example, when writing code, you learn that keeping data out of your code is a good thing. However, you need fixtures in your tests, so you have your data there. But how do you manage your fixtures? By keeping standardized fixture data in one place, you have a good refactoring, but it can resemble a strange "action at a distance" when running your tests. As a result, that's one of many areas where managing a large test suite can be cumbersome. (And no talk about "best practices for testing" would be complete without explaining the benefits of inherited tests).

    • Yes, something that shows the symbiotic relationship between tests and coding and debugging would be useful. Not sure how to formulate that.

      I'd never heard of the Liskov Substitution Principle [], but after reading the Wikipedia article it sounds like it's related to the protocol good neighbor principle "be lax in what you receive, strict in what you output".
      • Liskov is something that confuses a lot of programmers because it's often explain in arcane ways. Condider the explanation from the Wikipedia link you provided:

        Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

        Well, that's true, but since most of us aren't computer scientists, it can be confusing, particularly since many programmers don't realize that classes are merely types and operators are merely shortcuts for met