In my exploration of new Microsoft technologies, I’ve encountered the concept of scaffolding, particularly through tools like MvcScaffolding. Scaffolding is a well-known feature in other frameworks, such as Ruby on Rails, where it provides a quick way to generate code templates.
However, my encounter with scaffolding made me reflect on my high regard for Test-Driven Development (TDD) and how it influences my coding practices. TDD has significantly transformed how I approach code development—ensuring that my code is always driven by tests and that I don’t write unnecessary code.
The challenge arises with scaffolded code: it’s generated by a tool, not manually written. Should I write tests for this generated code? Should these tests be written before or after the code is generated?
Definitions
According to Wikipedia, scaffolding is:
Scaffolding is a temporary structure used to support people and material in the construction or repair of buildings and other large structures.
In programming, scaffolding refers to:
Scaffolding is a meta-programming method of building database-backend software applications. It is a technique supported by some model-view-controller frameworks, in which the programmer writes a specification for how the application database will be used. The compiler then generates code to create, read, update, and delete database entries, effectively using the template as a “scaffold” on which to build a more complex application.
A key difference between these definitions is the “temporary” aspect of physical scaffolding, which is removed once construction is complete. Scaffolded code, however, is intended as a starting point and should be integrated into the application’s core.
As Steven Sanderson notes:
“Scaffolding” is used by many software technologies to mean “quickly generating a basic outline of your software that you can then edit and customize.”
TDD
TDD is a methodology that emphasizes writing tests before writing the production code. It helps in defining what is needed and how it will be used before the code is written, ensuring that unnecessary code is not included. The tests provide a safety net, catching regressions or errors as the code evolves.
The Dilemma with Scaffolding
The issue with scaffolding is that it generates code without tests. This code, while functional, hasn’t been created with TDD principles in mind. Here are some thoughts on handling this:
- If the generated code is considered “mine”: I would prefer to write tests for it. This is especially important if the code will undergo changes. Tools like MvcScaffolding use templates that can be customized. I would recommend tweaking these templates to include tests for the generated code.
- If the generated code is considered “theirs” (i.e., third-party): Treat it as a black box. You may not want to delve into how it works internally. In this case, consider marking it as generated code using the DebuggerNonUserCode attribute or similar conventions.
Conclusion
These are my reflections on scaffolding and TDD. I’d love to hear your thoughts or recommendations on this topic. If there are established best practices that I’ve missed, please let me know. Otherwise, I’ll continue to navigate this area with the considerations outlined.