Find The Test Structure That Fits Your Team
A number of recent posts by Phil Haack, Ayende Rahien, and Gil Zilberfeld dealt with the topic of test organization. Each approach has its pros and cons, but neither is a silver bullet. Your (and your team's, project's) context determines which approach is right.
Without aiming to provide an exhaustive list, below are some questions that have influence on test organization:
- Is the team in a consulting project where test documentation is required as part of delivery?
- Is it a product team? Is the firm in its early stage or is it mature like Oracle with mature products?
- What is the turnover rate of the team? What are the plans for its growth? The team might have all the knowledge in their head, but if it'll double in size in a year, then the communication value of tests could increase.
- What is the maturity level of the team? How long have they been working together?
- How closely and often do team members collaborate?
- Is there collective code ownership?
- How does the team and its customers communicate? Some customers can - and willing to - read code, some need English (Turkish/Hungarian/German/etc.). Some teams have a level of (grown and deserved) trust that just saying the software works is accepted, some need a more formal acceptance and regression process.
- Is there proper IDE support for discoverability? Do all people reporting bugs (as tests) have access to that IDE? If not so, how do they find examples of how to write the bug-report test?
Feel free to add more questions in the comments!
