Ralph,

Thanks for the response. All of those seem a bit clunky, unfortunately.

- The Web URL seems extremely long, and would force the developer to use the Web interface, while over half of them on my team prefer to use Eclipse.
- The change set seems the cleanest, but if an existing test if failing and nothing's changed in the test code, there doesn't seem to be a need to create a change set.
- Attaching an artifact seems fine if it's just example/throwaway code, but if an existing test case is failing I'd rather not have multiple copies floating around. Perhaps the change could just be adding a comment about the defect.

I'm wondering if this is all pointing to a deficiency in how I've set up my Test project as a separate project from the Development projects. I'm not sure how I'd re-architect my structure to better coordinate with the developers' Work Items, though. Most of my tests will be integration tests and won't be associated specifically with one subsystem, so they wouldn't belong in the subsystem projects.

After chatting with one of my Lead Developers, I think I'm just going to put a description of where the test is located in my project in the Description of the Development Work Item. They're going to need to load parts of my project to see my tests, anyway. If that fails to work for them, we'll look for another solution.

Thanks again for the response.

-Jim

Hi Jim,

what I was able to do, was using the SCM Web UI, browse a stream for a file, copy the link location and add that as a related artefact. The develoer could click on it and it would open in the Web UI.

I am not sure that is what you want to do. I am not aware that it is possible to associate a file to a work item other than as

- Web URL (related artefact) like described above.
- Change set (not the actual file, but the change that is done to it and the other files in the change set)
- Attachment.