Indeed, maintenance is greatly simplified by having the code and tests within the same file.
It can be, depending on the project.
I'm no longer a fan of the "you must have one .t file for each logical module in your program" rule. I prefer my test files to have their own logical relationships, where each file tests one function of the program in a particular way. For example, in the Pod::PseudoPod::DOM test suite, I have separate subdirectories for each type of formatter and separate test files for each category of transformation (escapes, environments, block-level items, tables, and so on).
This does require a little bit of testing infrastructure, but organizing more than a few tests is like organizing more than a few lines of code. You choose the best option based on what you're doing and you change it to work better when it becomes necessary or obvious.
In reply to Re^4: Developing a module, how do you do it ?
by chromatic
in thread Developing a module, how do you do it ?
by mascip
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |