RE: [fitnesse] Test Package Refactoring...
- Let's go to 30,000 feet. What is the problem?-- The fixtures names are not communicative. Business people don't know what they mean.-- Moving fixtures between packages is a pain.Let's try an example:com.paychex.payrollSystem.fixtures.AddEmployeesClearly this is not a great name. It's full of lots of distracting information. What would be a good name?"Add Employees to Database"This is better, but not great. It implies that some action should be taken. That employees should be "added". Yet tests are not actions. Tests are assertions. A FIT test is a statement of what must be true, not a procedure to follow. FIT tests are declarative, not procedural. They are like "prolog" programs, not like "java" programs. (Indeed, I think every FitNesse page could be reduced to a set of Horn clauses)So perhaps this name is better:"Employees on Payroll"A standard ColumnFixture might look like this"|Employees on Payroll.||name|address|salary|date of birth|OK plunging back to the 12 angstrom level. What we need is a way to unambiguously indentify fixtures. The word "unambiguous" is critical here. The names of the fixtures all have to be unique, no matter how nicely they are spelled. Interestingly enough the need for unambiguous names is exactly the same need that we have for classes. So the two problems really aren't that different.If the two problems aren't that different, then why is there a problem? One reason there's a problem is that java class names don't allow spaces. Another problem is the package names that prefix the classes. If we can solve those two problems, we may be able to resolve the entire issue simply.Now as Jaque pointed out, the name "Employees on Payroll" can be easily translated back to a fixture name such as:EmployessOnPayrollFixtureLet's say we make a change to Fit so that it converts simple word strings to CamelCase as above, and then hunts through the available classpaths for any class that has that name. This solves a number of problems. First we don't have to change all the tests when fixtures move into different packages. Second it allows us to specify the Fixture names in a friendly (but still unique and rigorous) way.More details:I think we want the existing scheme to be grandfathered, and to take precedence. If the fixture name string unambiguously indenfities a class then we won't bother with the translation and searching specified above. Special characters and punctuation should be allowed, and should either be ingored or translated. For example: "Employee Table: Male & over 30" might translate to: EmployeeTableMaleOver30Fixture, or to EmployeeTable_MaleAndOver30Fixture. (I prefer the former)All directories in the !path (at least for Java) should be searched for the class. If there is a collision (two classes with the same name) then any that are in a package named 'fixtures' override those that don't. If there is still a collision then we throw an exception of some kind.The same translation is done for variable and function names.What do you all think of that?
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
> --- In firstname.lastname@example.org, "Patrick Parato" <pparato@c...>Eclipse (and I think IDEA, too), when doing a rename refactoring, lets
>> Is there an easy way to refactor the package where a fixture is
>> For example.....
>> ...for some good reasons we have a fixture that is run in a lot of
>> different tests and suites. Lets say that fixtures is called:
>> and we want to change the package name like this:
>> (so chickenhut -> chickentools)
>> Is there an easy way to do this?
you optionally also change fully qualified class names in text files. As
FitNesse pages are stored in plain text files, this works like a