Require JUnit test per component on delivery
Straight to business:
We have recently migrated to RTC/Jazz. In a simple case, we have one project area A with stream S. The stream contains multiple components (>40). When one of our developers starts working with a task, s/he adds a component to the private repo workspace, loads it, work, then send the changeset to the stream. All good.
We have recently migrated to RTC/Jazz. In a simple case, we have one project area A with stream S. The stream contains multiple components (>40). When one of our developers starts working with a task, s/he adds a component to the private repo workspace, loads it, work, then send the changeset to the stream. All good.
Now, we want to add the pre-condition that JUnit tests needs to be run before the changes can be delivered to the stream. This pre-condition should preferably be set per stream, but the only possible way is to set it per project area. First question: is it possible to set conditions per stream? Looking around other questions, the answers normally are "split your streams into more project areas" which isn't what we want (in practice we have ~20 areas with ~4 streams in each).
Second question: Is it possible to run the JUnit tests on only the component that has the changesets? It seems that you have to specifiy one master TestSuite that will run all tests specified in it (Project Configuration/Team Configuration/Operations Behavior/Deliver (client)/Require JUnit/JUnit Test Suite) . We don't want to run all tests for all components when we are fixing a minor bug in just one component. (we will run all tests at once in a later stage / build stage, so don't worry).
Thanks,
Daniel
Thanks,
Daniel
Accepted answer
Unfortunately Aruns answer does not cover the question completely.
This is not a trivial problem and there is, for all I know, nothing built into RTC that would easily support this entirely.
We have Advisors/preconditions on the client and the server that can be configured to prevent the delivery for certain conditions.
Please note, only the Eclipse client or development environment can know the result of the unit tests (unless you run a build on the server and use that as a proof).
The simplest approach to implement this would be to have an extension to the Eclipse client that somehow knows the necessary unit tests have successfully been run and prevents delivery if not. This would be similar to the clean workspace and no unused import client advisors, however, you would need some mechanism in Eclipse to check the condition that you could work against. There is none out of the box. This would have to be created.
The approach RTC takes is to allow the users to run personal builds and assume they are responsible enough not to deliver if that fails (assuming group pressure if they do).
RTC today does not implement the concept of "Gated Delivery" where the user would run a build with tests and only if the tests are successful would automatically deliver. We have had customers asking for that. This would be a potential solution.
We (well, I and some others) have also thought about the scenario described above and using personal builds. However, even with using personal builds it is hard to tell, which build result to test against if the delivery should be allowed (the user could sneak in changes).
I don't think there is a trivial solution to that today.
This is not a trivial problem and there is, for all I know, nothing built into RTC that would easily support this entirely.
We have Advisors/preconditions on the client and the server that can be configured to prevent the delivery for certain conditions.
Please note, only the Eclipse client or development environment can know the result of the unit tests (unless you run a build on the server and use that as a proof).
The simplest approach to implement this would be to have an extension to the Eclipse client that somehow knows the necessary unit tests have successfully been run and prevents delivery if not. This would be similar to the clean workspace and no unused import client advisors, however, you would need some mechanism in Eclipse to check the condition that you could work against. There is none out of the box. This would have to be created.
The approach RTC takes is to allow the users to run personal builds and assume they are responsible enough not to deliver if that fails (assuming group pressure if they do).
RTC today does not implement the concept of "Gated Delivery" where the user would run a build with tests and only if the tests are successful would automatically deliver. We have had customers asking for that. This would be a potential solution.
We (well, I and some others) have also thought about the scenario described above and using personal builds. However, even with using personal builds it is hard to tell, which build result to test against if the delivery should be allowed (the user could sneak in changes).
I don't think there is a trivial solution to that today.