Sipping and Test Driven Development (TDD)

Sipping: Systemically Incremental Programming


Overview
Sipping and Test Driven Development  may initially sound like they are one and the same thing.  Indeed, they are closely related, and aim to solve many of the same underlying problems.  Additionally, while not mutually exclusive, they do compliment each other well, and using TDD within the Sipping framework will produce excellent results.

That being said, they are different.


First though, how is Sipping similar to TDD
Many of the benefits associated with TDD are also present when using the Systemically Incremental Programming.  The benefits section of TDD on wikipedia served as the basis for this list of benefits of sipping:

Sipping drives the design of a program. By focusing on a complex problem SIP by SIP, one must imagine how the functionality will be used by clients, and how all of the SIPs will fit together, creating one, coherent system. 

As described in Ordering your SIPs, the programmer is concerned with the interface before the implementation. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions.

Sipping offers the ability to take small steps when required. It allows a programmer to focus on the task at hand, as all other complexities and distractions have been pushed into other, subsequent SIPs. Exceptional cases and error handling are not considered initially, and SIPs to create and test these extraneous circumstances are implemented separately. 

Unlike TDD, simple Sipping does not typically require more code, while, I believe, still providing many of the benefits of TDD that make the implementation times for TDD shorter.^[10] Large numbers of individual SIPs help to limit the number of defects in the code in the same way that large numbers of Tests under TDD do. The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project.  TDD and Sipping share this benefit equally.

Sipping tends to lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces. The use of the mock object design pattern also contributes to the overall modularization of the code because this pattern requires that the code be written so that modules can be switched easily between mock versions for testing and "real" versions for deployment.

Because no more code is written than necessary to complete the SIP, it is generally easier for the developer to actually test all of this code, which he does as a matter of practice, before committing each SIP. 

How is Sipping different from TDD?
Specifically, I would categorize TDD as a subset of Sipping.  In other words, TDD does not specifically address how to break a problem apart.  Instead, it describes what to do once each "test" has been identified.  The "failing test" referred to in TDD would typically be the goal of a single SIP.

Where TDD seeks to describe how to implement one SIP, Systemically Incremental Programming describes the process of how to take complex problems, and pull them apart into separate SIPs in the first place.

TDD is also a relatively highly structured process, that relies on automated testing systems (Unit Testing for example).  Sipping is a more general set of guidelines that aims to solve a similar problem, but does not address directly how each "SIP" should be validated.  TDD (in many cases) will be an excellent choice for how to validate that the SIP has been completed to spec, but sipping works even if Testing is not the method of validation

Interestingly, going back to Wikipedia, virtually all of the "Vulnerabilities" listed for TDD do not apply to Sipping because most of the vulnerabilities of TDD are related to the overhead of initially creating and maintaining the TDD tests.  Sipping does not require this overhead.  Again, if used in conjunction with TDD, they may still be present - but they are absolutely not a prerequisite of Sipping.

The one vulnerability that both share (which was, however, not listed as a vulnerability of TDD) is that the incremental design process that both encourage, does not necessarily result in the most efficient overall system design.  Subsequent refactoring of the code may be required if performance is identified at any point during the testing process.  See Sipping, Code Efficiency and Preemptive Optimization for more information on this issue.

Conclusion
As you can see, Sipping TDD are closely related to one another, but not mutually exclusive.  The biggest difference is that in it's fundamental methodology design, Sipping does not require unit tests to be written for each SIP, but rather, this would be an optional extension to the implementation of an individual SIP.  This reduces the required overhead to starting using the Sipping method - as it can be applied to any project, any time, anywhere - giving SIP developers many of the advantages of TDD, without the test code overhead.