It's all about the answers!

Ask a question

Is there an ANT task to to create a Defect?


Raphael Chancey (36109) | asked May 22 '12, 11:25 p.m.
I am looking to auto create Defects based on my JUnit test case execution.. I was not able to find an ant task for that.

Any suggestions?

8 answers



permanent link
Ralph Schoon (63.1k33646) | answered May 23 '12, 2:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I am looking to auto create Defects based on my JUnit test case execution.. I was not able to find an ant task for that.

Any suggestions?


As far as I am aware there is none.
This has been discussed quite often, so you might want to submit an enhancement request. I couldn't find one (too many hits).

https://jazz.net/forums/viewtopic.php?t=20470 discuses this and also provides links and code how to create a small tool to create work items using a self built java tool.

Finally this blog talks about how to create a custom ANT task: http://ryehle.wordpress.com/

permanent link
Ralph Schoon (63.1k33646) | answered May 23 '12, 2:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
And if you want to get started with the build API, this is a good starter: https://jazz.net/library/article/807

permanent link
Raphael Chancey (36109) | answered May 24 '12, 10:13 a.m.
And if you want to get started with the build API, this is a good starter: https://jazz.net/library/article/807


Thank you .. we implemented this last night.. .. wonderful step in our fullly automating our build/test.

permanent link
Ralph Schoon (63.1k33646) | answered May 25 '12, 2:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Please provide feedback, needs and experience on your way to automation if possible. I am always very interested in real life feedback and things we could do to enhance the experience. You can comment on the article or also e-mail me.

permanent link
Raphael Chancey (36109) | answered May 25 '12, 10:37 a.m.
Please provide feedback, needs and experience on your way to automation if possible. I am always very interested in real life feedback and things we could do to enhance the experience. You can comment on the article or also e-mail me.


I could write a small book on our experience with trying to automate things leveraging RTC over the last few months... not all of it good.. some of it great.

I can send you a detailed email... but in general:
1) RTC is a life saver.. I tell you I think it is one if the greatest products / capabilities I have worked with. I absolutely don't know how we ever lived without the capabilities that are in RTC... from a code mangaement, work item management, build management, team collaboration .. using something as simple as the discussion area.. just an amazing platform.

2) In general my experience has been RTC does not have great support for automation.. some fundamental features are missing that in my mind should have been in Version 1.. like auto assigning a defect to a person who owns the component the defect is against.. . and like this thing.. have built in capability to generate a defect based on failed test case... stuff like that should be a check box in a widget.. QED

3) In general..my feeling is the 'religion' around RTC is to have people doing everything manually.. .. if you read though the forums, read through the requirements and what is delaying a lot of them.. is this feeling that 'people' should be doing stuff. In my, potentially limited, experience with clients.. that is the exact opposite of what customers are wanting and where we are going in product development. Even the QCert people are pushing for more automatioin across the board. So I think this is wrong.. .. we should be providing as '1st class' citizens.. the capability to automate the heck out of everything.. and manual intervention is the exception.

4) I was never ever able to get my eclipse environment set up so that I could create an extension to RTC UI.. that has sucked bad... .to this day I can't get that working.. need an updated guide for that that is current.

5) need rich text capability in teh discussion area for work items will become critical.. . in line pictures would be great.... (think never creating a word document ever again .. rather put hte text in line with the work item and it is always living.. yah!).. the file attach is ok.. but just not as native as i could be to really make the collaboration truely seemless..

permanent link
Ralph Schoon (63.1k33646) | answered May 25 '12, 11:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Raphael,

thanks for the feedback.

As a starter https://jazz.net/library/article/784 is a good source for links.
To set up your development I would suggest following https://jazz.net/library/article/634 really very accurate. It has worked for me and a couple of other people very well. The issue is if you are not careful with which checkboxes and buttons to press, you get into trouble, especially in the setup phase. We are planning to submit an update for the next release, if necessary.

I agree, that having as much automation as possible should be the aim.

However, I am not necessarily a fan of all automation. 8-) I think an automate can't (yet) do conscious decisions and if automation creates unnecessary data it should be avoided.

For example creating a work item for each build error. The issue I have with it, if you have too many work items created that are worthless and get swamped with useless e-mails you are going to hate the additional work. We have feeds for instance that indicate the build issue. I think it would be useful for some streams e.g. the main integration, for builds that are scheduled by a timer however.

Another issue I see is, that we do not necessarily have the metadata. Who is the lead of the component? The lead of the team that owns it? Do we need to have a special attribute? Some would want this on project level. Or file level.

What is a component? Some users would like to have dependencies and subcomponents. Reasonable. But it will take time to implement all that and what is the general business logic everyone can agree to?

There are other questions that come up if you think about a general implementation of such capabilities. Another is, how to detect the RTC project that the defect should automatically be created in when the test case fails? There could be more than one.

It will take time to understand what user want and to find something that works for most users out of the box. I would create enhancement requests for things I feel are missing.

And I would attend the Jazz Planning JAM: https://jazz.net/blog/index.php/2012/05/23/jazz-plan-jam/

I agree, that if someone wants the work items to be created however, it should be possible. There is a lot that can be done with extending RTC, but there is a certain steep learning curve and a lot of API's and Frameworks you need to know to do this. We try to help and are trying to create more examples and articles, if we can find the time. So stay tuned.

permanent link
Raphael Chancey (36109) | answered May 25 '12, 2:18 p.m.
Hi Raphael,

thanks for the feedback.

As a starter https://jazz.net/library/article/784 is a good source for links.
To set up your development I would suggest following https://jazz.net/library/article/634 really very accurate. It has worked for me and a couple of other people very well. The issue is if you are not careful with which checkboxes and buttons to press, you get into trouble, especially in the setup phase. We are planning to submit an update for the next release, if necessary.

I agree, that having as much automation as possible should be the aim.

However, I am not necessarily a fan of all automation. 8-) I think an automate can't (yet) do conscious decisions and if automation creates unnecessary data it should be avoided.

For example creating a work item for each build error. The issue I have with it, if you have too many work items created that are worthless and get swamped with useless e-mails you are going to hate the additional work. We have feeds for instance that indicate the build issue. I think it would be useful for some streams e.g. the main integration, for builds that are scheduled by a timer however.

Another issue I see is, that we do not necessarily have the metadata. Who is the lead of the component? The lead of the team that owns it? Do we need to have a special attribute? Some would want this on project level. Or file level.

What is a component? Some users would like to have dependencies and subcomponents. Reasonable. But it will take time to implement all that and what is the general business logic everyone can agree to?

There are other questions that come up if you think about a general implementation of such capabilities. Another is, how to detect the RTC project that the defect should automatically be created in when the test case fails? There could be more than one.

It will take time to understand what user want and to find something that works for most users out of the box. I would create enhancement requests for things I feel are missing.

And I would attend the Jazz Planning JAM: https://jazz.net/blog/index.php/2012/05/23/jazz-plan-jam/

I agree, that if someone wants the work items to be created however, it should be possible. There is a lot that can be done with extending RTC, but there is a certain steep learning curve and a lot of API's and Frameworks you need to know to do this. We try to help and are trying to create more examples and articles, if we can find the time. So stay tuned.

Wrong answer.. you are supposed to say 'you are right.. you walk on water... and we will implement all this by next week'..

hee hee
kidding asside.. What is wrong with creating a 'Test Case' work item and associating it to a JUnit test case.. and pulling information from that? asside from the obvious 'why that is RQM!' ... this would make test cases 'living' documents rather than word docs.. then we can set that against a component with an owner.. and always will be in RTC for ever and ever and always living..

comments?

permanent link
Ralph Schoon (63.1k33646) | answered May 25 '12, 3:42 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER


He he...

I think this really very dependent on situation, department or company politics. The (method) discussions get esoteric very quickly. So, as a summary, if it works for you or seems to be desirable and you can do it, go for it. Stay flexible if you discover the process does not work for you.

With respect of making Unit test formal test, my - really personal - opinion..

It really depends on the setup. Unit tests are usually provided by development. It is not necessarily their desire to have their unit tests, that they develop to make sure the code works as expected, a formal test case for QS. QS also does test other aspects (functional, UI, use case driven).

And dependent on the setup, it could have several consequences. Do they have to maintain it? Is the unit test a delivery? Is it necessary to plan for it? Design documents for changing unit test cases. I guess you can get pretty paranoid if you follow this train of thought. Worse if you start thinking about subcontractors and unit tests being a delivery.

Just some different angles to look at it I guess.

And of course you are right.. you walk on water... and we will implement all this as soon as we can, provided there is an enhancement request for it that gets enough attention at Jazz Plan Jam: https://jazz.net/blog/index.php/2012/05/23/jazz-plan-jam/

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.