By the way, given this is a Fit blog …. a few years before Rick Mugridge got into co-inventing Fit, he used to get his grad students to do little mini-projects extending Naked Objects. I remember Rick was in the UK and also demo’ed this new “Fit” thing. None of us got it.

A couple of years on, we’re now using Fitnesse for the big NO system for the Irish Government, and it’s working very well. At some point I’d like to extend NO to provide Fitnesse support “out-of-the-box”, so if anyone is reading this and wants to contribute…

Cheers
Dan

Ironically, I have maybe done one or two projects in my entire career that were targeted purely at the Serbian market. Even then, the code was in English because most libraries have methods named in English and it looks silly when languages are mixed. I think that acceptance tests work only if people can use them for discussion so they should be in whatever language the business is, which in your case is probably French. If the code is in English, then the ubiquitous language principle is not really used, but a simple name mapping from one language to another should not be hard to implement, especially if externally configured. Python supports really flexible renaming by default, something similar would probably benefit a lot both Java and .NET runners. Internationalisation is definitely one of the things that should be done soon.

I guess I’m just suggesting that if you do provide methods in newer versions of FitNesse that do use some sort of natural language processing that those methods be externalized into rules somehow so the rules can be translated. For instance, removing the letter ’s’ from the end of a method name as you mention in your posting would work for English but not French/Spanish/etc.

Maybe it would be easier to use the config suite mechanism to allow the user to map language onto objects however they want?? Maybe you already discussed that but if not then i’ll throw it out there. This way:

1. You’re not confining yourself to a particular language
2. There’s no ambiguity as with natural language processing
3. there is still no boiler-plate code per se (though you would need to define rules in the suite config)

what do you think? I think there are some good rule-engines out there that might provide some inspiration for this?

p.s. I really love Fitnesse, it has totally changed the way I develop. I’ve always been a believer in test-riven development but fitnesse makes TDD so much easier. I am spreading the good word amongst people in my department as much as I can! I/we really appreciate the work you (et al.) have done in making this tool!