Hier die app.js:

const random = Math.random() * 100 // random ms of time
const btn = document.createElement('button')
document.body.appendChild(btn)
setTimeout(() => {
  // add the class active after a random amount of time
  btn.setAttribute('class', 'active')
}, random)

und der dazugehörige Test in der test.cs.js:

it('does something different based on the class of the button', () => {
  // RERUN THIS TEST OVER AND OVER AGAIN
  // AND IT WILL SOMETIMES BE TRUE, AND
  // SOMETIMES BE FALSE.
  cy.get('button').then(($btn) => {
    if ($btn.hasClass('active')) {
      // do something if it's active
    } else {
      // do something else
    }
  })
})

Ist dieser Test deterministisch?

Folgende Konfiguration ist für die Erstellung von HTML-Reports notwendig:

const { defineConfig } = require('cypress')
module.exports = defineConfig({
  reporter: 'mochawesome',
  reporterOptions: {
    reportDir: 'cypress/results',
    overwrite: false,
    html: false,
    json: true,
  },
})

Welche Aussagen treffen hier zu?

Im File cypress.config.ts der Beispiel Implementierung von Cypres-Realworld-App findet sich folgende Konfiguration:

    setupNodeEvents(on, config) {
      const testDataApiEndpoint = `${config.env.apiUrl}/testData`;
      const queryDatabase = ({ entity, query }, callback) => {
        const fetchData = async (attrs) => {
          const { data } = await axios.get(`${testDataApiEndpoint}/${entity}`);
          return callback(data, attrs);
        };  
        return Array.isArray(query) ? Promise.map(query, fetchData) : fetchData(query);
      };  
      on("task", {
        async "db:seed"() {
          const { data } = await axios.post(`${testDataApiEndpoint}/seed`);
          return data;
        },  
        "filter:database"(queryPayload) {
          return queryDatabase(queryPayload, (data, attrs) => _.filter(data.results, attrs));
        },  
        "find:database"(queryPayload) {
          return queryDatabase(queryPayload, (data, attrs) => _.find(data.results, attrs));
        },  
      }); 
      codeCoverageTask(on, config);
      return config;
    },

Welche Aussagen treffen hiermit zu?

Bevor E2E-Tests geschrieben werden, sollte eine Teststrategie definiert werden, die die wichtigsten Bereiche der Anwendung für die Testabdeckung visuell dokumentiert. Ein empfohlener Ansatz besteht darin, zunächst alle Anwendungs-Views zu dokumentieren und dabei Notizen zu den Funktionen zu machen, die auf jeder View getestet werden müssen.

Wenn die Anwendung im Voraus durchgedacht wird, ist das Schreiben der Tests viel einfacher. Außerdem kann die Arbeit auf verschiedene Entwickler, Tickets usw. aufgeteilt werden. Visuelle Dokumentationen wie das obige Beispiel fungieren als eine Art „Karte“, die einen guten Überblick über die Testoberfläche der Anwendung bietet.

Betrachten Sie folgende Anforderung: „Ein Webshop führt einmal täglich einen Batch-Job aus, um alle bezahlten Bestellungen auszuliefern. Das Lieferdatum wird dabei abhängig davon festgelegt, ob es sich um eine Bestellung eines internationalen Kunden handelt. Die Bestellungen werden aus einer externen Datenbank abgerufen. Bezahlte Bestellungen werden anschließend an einen externen Webdienst übermittelt.“

Als Tester müssen Sie entscheiden, welche Testebene (Unit-, Integrations- oder Systemtest) Sie anwenden. Welche der folgenden Aussagen sind richtig?