Here is the concrete problem I faced in writing test cases within a team of couple of coders:
Each of coder writes test cases against their own classes. Each test case has certain configuration associated with it. Most of the configuration can be shared between coders but there are certain properties, which are specific for each coder. By shared properites I assumed ones, which can be set within test cases and run on each of coder's machines. Example of non-shared properties would be different connection string (for database) for each coder. Each of us want to use separate database since we do not want to intersect with each others data while writing test cases or running them. I know that one of the advices ("J2EE Development without EJB") state that unit tests should not use external resources. I could agree on that. But what about integration tests? Some of the coders want to write some of those tests also. Performance tests falls into same category. For those tests external resources are important.
Second problem was web.xml file or Spring application context shared between coders and QA. Both contain set of properties, which potentially have different values for each coder and each QA.
Question is: where to put such kind of overlaps? where to keep safe copy? source control? Some of them can be pretty big and I do not want to write them again in case of what ever failure on my local machine. Also I would like to download complete source tree from source control on my home machine (when I work from home) and be set to go almost instantly from the point where I stopped in office. Particular interesting case is this "home case". Within the office all coders could share one development server with Oracle instance and with separate databases. At home I need to have local Oracle instance in order to verify tests before checking-in modification into source control.
One solution which I envisaged in my coding strategy is to use variables in Spring application context files in place of overlapping (non-shared) properties. Each coder would keep his set of properties for his own test cases. I also wanted checked-in those properties files. They will reside in test part of source tree and I didn't see as big problem to have "personalized" files in source control managed in that fashion. Test cases are rarelly shipped with commercial application, so no harm to have them as part of test tree.
I am sorry for a bit long post, but I had couple of long debates within my team on the subject and I would like to hear some Spring experiances.


Reply With Quote