"There are only two hard things in Computer Science: cache invalidation and naming things". Phil Karlton.
An area of contention in the re-design of OTS to accommodate Six Pack is what defines a TestPlan.
I would hope that by falling back on some basic principles we can improve the naming in OTS.
Domain specific naming (by domain I mean the testing of Maemo phone devices) has been rife. To a certain extent this is inevitable in the early days of a software system when the problem being solved is often hazy and requirements unclear. We are no longer at that stage.
Domain specific names could be seen as a sign of "understanding the end user", and not using them "disloyal". This is a fallacious argument; all it does is oblige an incoming Software Engineer to have an understanding of the domain (and often the specific culture) whilst allowing the author Developer to be lazy in naming. The end result is obfuscated code. I am pretty sure that we aren't in a "top trumps" culture ("I have been 10 years writing software for Acme apps and an AcmeFoo is a blah, blah, blah and I know it!"?). By demonstrating an understanding of the *Problem* and naming accordingly we avoid these issues.
Use Solution Domain Names
e.g. Think twice the next time you want to use terms such as "device", "results" etc. If it helps you 'Think Django': do we see "GigModels" or "EntertainmentSettings" when we use the Framework?
Less perhaps important but worth noting is that the "Test" prefix was all over the code like a rash. Again how does this help the reader of the code? In fact how does it help us in creating OS software? It is potentially off-putting when trying to recruit Developers from other domains who have common functional requirements. (It also makes "nose" difficult to use!)
Don't add Gratuitous Context
So for our "TestPlan": what does this convey to an outsider? Something that "plans the test"? What about the "TestDefinition" something that "defines the test"?. Does the naming present clear difference of purpose between these two scripts?
These are problems that nomadic developers hit on in proprietary systems and seemed general enough to be worthy of a blog or guidelines and sure enough a bit of googling gave me this: http://www.objectmentor.com/resources/articles/Naming.pdf to which I owe the sound-bite phrases for the two recommendations to this document. These are cut and paste below:
Go ahead, use computer science (CS) terms, algorithm names, pattern names, math terms, etc. It may seem a heretical notion, but you don't want your developers having to run back and forth to the customer asking what every name means if they already know the concept by a different name. We're talking about code here, and you're more likely to have your code maintained by an informed programmer than by a domain expert with no programming background. End users of a system very seldom read the code, but the maintainers have to. Solution domain names are appropriate only if you are working at a low-level where the solution domain terms completely describe the work you are doing. For work at a higher level of abstraction, you should Use Problem Domain Names (below).
In an imaginary application called "Gas Station Deluxe", it is a bad idea to prefix every class with `GSD'. Frankly, you are working against your tools. You type G and press the completion key, and are rewarded with a mile-long list of every class in the system. Is that wise? Why make it hard for the IDE to help you? Otherwise, the regular developer will have to learn to ignore the GSD at the front. Likewise, say you invented a `Mailing Address' class in GSD's accounting module, and you named it GSDAccountAddress. Later, you need a mailing address for your customer contact application. Do you use `GSDAccountAddress'? Does it sound like the right name? 10 of 17 characters are redundant or irrelevant Shorter names are generally better than longer ones, if they are clear. Add no more context to a name than is necessary. The names `accountAddress' and `customerAddress' are fine names for instances of the class Address but could be poor names for classes. Address is a fine name for a class. If I need to differentiate between MAC addresses, port addresses, and web addresses, I might consider PostalAddress, MAC, and URI. The resulting names are more precise, and isn't precision the point of all naming?