Ich möchte Canopy Web-Testergebnisse in VS 2013 Test Explorer zeigen ... und ich bin SO SCHLIESSEN

Question

Ich versuche herauszufinden, wie die Testergebnisse für Canopy im VS-Test Explorer angezeigt werden. Ich kann meine Tests bekommen und sie werden laufen, aber es zeigt immer einen Pass. Es scheint, als würde die Run() - Funktion die Ergebnisse "essen", so dass VS niemals einen Fehler sieht.

Ich bin sicher, es ist ein Konflikt zwischen wie Canopy die Ausnahmen gut interpretiert, die Testergebnisse erhalten, weil normalerweise Run() unabhängig vom Ergebnis erfolgreich sein und seine Ergebnisse mit eigenen Berichten melden soll.

Vielleicht sollte ich die Ausgabe umleiten und das im MS-Testcode interpretieren?

Also hier ist, wie ich es haben jetzt einrichten ...

Der Visual Studio Test Runner sieht in dieser Datei für das, was sie als Tests sieht, diese die Canopy-Methoden aufrufen, die die reale Tests durchführen.

open canopy 
open runner 
open System 
open Microsoft.VisualStudio.TestTools.UnitTesting 

[<TestClass>] 
type testrun() = 

    // Look in the output directory for the web drivers  
    [<ClassInitialize>] 
    static member public setup(context : TestContext) = 
     // Look in the output directory for the web drivers  
     canopy.configuration.ieDir <- "." 
     canopy.configuration.chromeDir <- "." 

     // start an instance of the browser 
     start ie 
     () 

    [<TestMethod>] 
    member x.LocationNoteTest() = 
     let myTestModule = new myTestModule() 
     myTestModule.all() 
     run() 


    [<ClassCleanup>] 
    static member public cleanUpAfterTesting() = 
     quit() 
     () 

myTestModule sieht aus wie

open canopy 
open runner 
open System 

type myTestModule() = 

    // some helper methods 

    member x.basicCreate() = 
     context "The meat of my tests" 

     "Test1" &&& fun _ -> 
      // some canopy test statements like... 
      url "http://theURL.com/" 

      "#title" == "The title of my page" 

      //Does the text of the button match expectations? 
      "#addLocation" == "LOCATION" 

      // add a location note 
      click ".btn-Location" 

    member x.all() = 
     x.basicCreate() 
     // I could add additional tests here or I could decide to call them individually 

Answer 1

Ich habe es jetzt funktioniert. Ich lege das nach dem Lauf() für jeden Test.

Assert.IsTrue(canopy.runner.failedCount = 0,results.ToString()) 

so jetzt sehen meine Tests so etwas wie:

[<TestMethod>] 
    member x.LocationNoteTest() = 
      let locationTests = new LocationNote() 

      // Add the test to the canopy suite 
      // Note, this just defines the tests to run, the canopy portion 
      // of the tests do not actually execute until run is called. 
      locationTests.all() 

      // Tell canopy to run all the tests in the suites. 
      run() 

      Assert.IsTrue(canopy.runner.failedCount = 0,results.ToString()) 

Canopy und die Infrastruktur haben Unittesting eine gewisse Überlappung in dem, was sie kümmern wollen. Ich möchte, dass die UnitTesting Infrasturktur das Ding ist, das die Zusammenfassung aller Tests und Details "berichtet", also musste ich einen Weg finden, den Überdachungsteil neu zu "resetten", so dass ich den letzten bekannten Zustand von der Überdachung und dann nicht verfolgen musste vergleichen. Damit dies funktioniert, kann Ihre Überdachungs-Suite nur einen Test haben, aber wir wollen so viele haben wie wir wollen auf der UnitTesting-Ebene. Um das zu tun, machen wir das unten in [].

runner.suites <- [new suite()] 
    runner.failedCount <- 0 
    runner.passedCount <- 0 

Es könnte sinnvoll sein, etwas in Vordach zu haben, die genannt werden könnten oder konfiguriert, wenn der Benutzer wünscht, eine andere Einheit Prüfinfrastruktur um Vordach zu verwenden.

Darüber hinaus wollte ich die Ausgabe, die die Fehlerinformationen enthält, wie es normalerweise bei einem Test fehlschlägt, so dass ich die console.out in einem StringBuilder erfassen und deaktivieren Sie in []. Ich richte es ein, indem ich das folgende [] einschließe, wo common.results der StringBuilder ist, den ich dann in den Behauptungen verwende.

System.Console.SetOut(new System.IO.StringWriter(common.results)) 

Answer 2

einen wandelbaren Typ erstellen in den ‚myTestModule.all‘ Aufruf zu übergeben, die entsprechend bei einem Ausfall aktualisiert werden kann und behauptet auf nach ‚run()‘ abgeschlossen ist.