Recently by Phlip Plumlee

No matter what your version control system, your command to throw away a batch of changes is your best friend -- if you use your test rig correctly.
While Extreme Programming remains a valuable template for project success, the decade of its adoption also saw the rise of many dilutions and derivatives. This post debunks some common myths about TDD.
My last post showed how to mock a webservice. When you have more than one webservice, all their common code, tests, and mocks should remain DRY. This post demonstrates a ruthlessly effective test pattern that forces many different interfaces to behave as similarly as possible, using the minimum possible test code.
This post shows how to write a web service using Test-Driven Development. Our source code example is the exemplary active_merchant contribution to Ruby on Rails. It reveals how developer tests can correctly attack remote web services. Programmers writing clients (or servers) for any kind of web service should use these techniques. My next post will extend this one into the Abstract Test Pattern.
Well-factored code often has many small functions. If each adds value, and doesn't just pass the buck, then what do they all do? Typically, they contract their input by making it more specific. Then they delegate these specific data to a delegatee.
I have upgraded several Rails 1.2.x programs to 2.x. This can be quite a leap, and some of the steps are counterintuitive, so this post attempts to put everything together, like a recipe. I'd also like to hear more stories about upgrading platforms; such stories may indeed emend my suggested hacks and tweaks. Yet the point of unit tests, and TDD, is to make the smallest changes possible, and relentlessly test each change. Upgrading a major version tick is a big change, so you must force the upgrade to work incrementally, as a series of small changes.
All blogs correlate their posts with tags. This blog post shows how to use these tags to display a mind map, hooking the current post into a tree of related posts.
Test Driven Development works best when each test case targets one aspect of a class's interface. So this post will demonstrate a simple and direct way to test a partial without testing the Views, layouts, and Controller actions surrounding it. On very complex projects, this technique keeps your partials decoupled.

News Topics

Recommended for You

Got a Question?