2011-09-09 9 views
6

ho notato c'è un Microsoft.VisualStudio.TestTools.UnitTesting.WorkItemAttribute attributo disponibile nei test di Visual Studio (sto usando VS 2010 Premium e di lavoro con gli elementi TFS 2010.)Usa per WorkItemAttribute?

Marcatura un metodo di test con un numero di elemento di lavoro sembra a portata di mano, ma in realtà fa qualcosa? Non riesco a capire se esiste un supporto per gli strumenti. Ho impostato uno in questo modo:

[WorkItem(25788)] 
[TestMethod] 
public void TestSomethingSpecificToABug() 
{ 
    ... 

Ma nessuna magia - ho pensato che forse il menu contestuale sulla prova nella finestra Risultati del test potrebbe offrire per aprire l'elemento di lavoro, o Team Explorer potrebbe avere una funzione per la ricerca di test. Il MSDN documentation non è di aiuto neanche. A cosa serve questo attributo?

risposta

3

Secondo "Software Testing with Visual Studio® 2010" di Jeff Levinson (Addison-Wesley Professional, Febbraio 2011, ISBN-10: 0-321-73448-3):

Questo significa anche che una proprietà esistente non dovrebbe essere usato più: Elementi di lavoro associati. Questo valore non è riportato nel data warehouse e pertanto non può essere utilizzato per la segnalazione. Se attualmente utilizzi questa proprietà, considera la possibilità di associare il test a un vero e proprio test Tipo di lavoro del caso .

Quindi la risposta è, non utilizzare questo con TFS 2010.

1

È per collegare il test dell'unità a un elemento di lavoro in TFS. Fornirei un collegamento a più informazioni ma sembra che sia davvero scarsamente documentato.

Non l'ho usato da solo ma credo che possa essere utilizzato per generare report sullo stato degli elementi di lavoro.

3

attributo WorkItem Metodo di prova non viene utilizzato per associare metodi di prova per testare i casi. Viene in genere utilizzato per associare un metodo di test a un bug. Una correlate C# esempio dalla Code Index - How to discover ignored tests:

Quando si utilizza MSTest per costruire la vostra suite di test di unità, è possibile utilizzare l'attributo [Ignora] per dire al motore di MSTest di non eseguire un test, invece di commentare esso. Si può anche utilizzare l'attributo [WorkItem (id)] per link unit test a un database di bug (come TFS) elemento, in modo che si possibile rintracciare il motivo per cui un particolare test è stata contrassegnata come ignorata:

[Ignore] 
    [WorkItem(12345)] // bug 12345 describes why this test was ignored 
    [TestMethod] 
    public void IgnoredButWithWorkItemTest() 
    { 
     //The actual code is not important; 
    } 
0

Ricordo davvero di aver usato questo Attributo prima ei risultati del test sono stati allegati al rispettivo oggetto WorkItem.

Tuttavia, con Visual Studio 2012, non funziona più, o ho dimenticato quale meccanismo era effettivamente responsabile per la magia. Potrebbe essere che funzioni solo attraverso il server di build?

1

Questo purtroppo non si più necessario: in VS 2013 tramite CodeLens

Trova elementi di lavoro collegate (Alt + 7)

enter image description here

Trovare le revisioni del codice collegate (Alt + 8)

enter image description here

bug Trova collegate (Alt + 9)

enter image description here

di rivedere la definizione di un test, fare doppio clic sul test.

enter image description here

Oh! per coloro che amare Lync:

contatto con il proprietario di un elemento (Shift + F10)

enter image description here

0

Tirando attributi dal binario di prova è veramente utile quando si dispone di un cablaggio a casa di prova cresciuto costruita per eseguire test di unità UI Selenium.

Dopo un errore di test, è possibile estrarre il valore WorkItemAttribute utilizzando System.Reflection.MemberInfo.CustomAttributes e quindi cercare l'ID con l'API TFS. Se l'elemento di lavoro è un bug ed è ancora attivo, posso risolvere automaticamente l'errore relativo a quell'errore. In questo modo, posso eseguire il test di malfunzionamento ogni giorno e risolvere automaticamente l'errore di ridurre la randomizzazione.