Actually, I'll have to say, "Au Contrare" in your suggestion to nix "sharing" script files between projects. If you think about it, if there are two applications under development in a company, both of which need objects to be able to retrieve SQL queries as Record Sets, it's BAD practice to create two different objects in code that do EXACTLY the same thing because it creates a maintenance problem... you update one, you need to make sure you update the other.
In a previous life, we had a set of code that was "Common" to all our automation projects. That way, rather than needing to copy a unit of code, we just did an "add existing". Now, this code was "generic" enough... things like I mentioned above where we needed to create objects and such that were in common use... And, by having all projects point to the same actual code unit and folder, if it got updated (like a bug got fixed) it was fixed in all projects immediately.
Basically, when you get down to it, maintaining a robust test automation suite needs to use MANY of the same techniques as you do in maintaining a robust and mature application's code base.
Robert Martin
[Hall of Fame]Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available