BDD di componenti dell'interfaccia utente con watin e specifico

Question

La mia domanda è focalizzata se la mia configurazione sta attualmente seguendo un approccio alle migliori pratiche riguardanti BDD con test di accettazione dell'interfaccia utente. Sto usando Watin con SpecFlow per costruire i miei test di accettazione dell'interfaccia utente e sto distribuendo la mia applicazione su Appharbor (una piattaforma cloud come servizio per applicazioni .NET). Appharbor esegue i test dell'unità/integrazione al momento della distribuzione e spinge il tuo sito solo se i test passano. Così ho iniziato prima scrivendo un test di base di base come segue:

Scenario: Navigation to homepage
          When I navigate to /
          Then I should be on the application homepage

I passaggi associati a questo test aprono un browser usando Watin e verificano che l'attributo del titolo della vista è impostato su "Welcome". Sto facendo un controllo sull'ambiente per decidere su quale URL testare con il browser Watin. Ad esempio, se in sviluppo vai a "http: // localhost: 49641/" per casa. Altrimenti, vai a "http://myappharborapp.com/".

Il mio problema è che se stai distribuendo questa applicazione per la prima volta, la pagina o la vista effettivamente non esiste e quindi il test non riesce (perché il sito non è ancora in diretta). Ciò fallirebbe anche se, ad esempio, avrei successivamente aggiunto una visualizzazione di pagina "Informazioni" e prima scrivessi un test di fallimento. Quando spingo gli aggiornamenti, il test fallirà perché la pagina "Informazioni" non esiste ancora.

La mia domanda è allora: non sto seguendo le migliori pratiche per quanto riguarda come dovresti impostare i test dell'interfaccia utente? Come dovrebbero essere configurati questi test in modo che passino in qualsiasi ambiente?

Qualsiasi consiglio é ben accetto!

Answer 1

Nei test Watin "tradizionali" utilizzo attributi personalizzati per specificare quale versione di un'applicazione e in quale ambiente è in esecuzione, e quindi il test viene saltato se la critiera è persa.

(Il codice è open source in a http://testingstax.codeplex.com Nel campione ParkCalc> Observer> Monitor ambientale)

    internal static void CheckSetEnvironment()
    {
        Object[] attributes = Utility.GetCallerAttributes(typeof(ExecutionEnvironment), 3);

        CheckEnvironment(attributes);
    }

    private static void CheckEnvironment(Object[] attributes)
    {
        TestEnvironment = GetCurrentEnvironment();

        if (attributes.Length > 0 && !attributes.Contains(new ExecutionEnvironment(TestEnvironment)))
        {
            Assert.Inconclusive("This test is not designed to be executed in the '" + TestEnvironment.ToString() + "' environment.");   
        }
    }

    private static EnvironmentType GetCurrentEnvironment()
    {
        string currentEnvironment = ConfigurationManager.AppSettings["Environment"].ToLower(CultureInfo.CurrentCulture);
        EnvironmentType Environment = new EnvironmentType();

        try
        {
            Environment = (EnvironmentType)Enum.Parse(typeof(EnvironmentType), currentEnvironment, true);
        }
        catch (System.ArgumentException)
        {
            Assert.Fail(" The current environment setting in 'Environment' in the app.config is invalid.");
        }
        return Environment;
    }

Il trucco sarebbe quindi di mappare un'azione SpecFlow per ignorare il test

"Dato che il test non è in produzione" o qualcosa di simile