Skip to main content
Die Trailblazer Community auf Slack befindet sich jetzt in der offenen Betaphase – treten Sie bei und tauschen Sie sich in Echtzeit aus. Kommen Sie zu uns auf Slack

Erste Schritte mit Apex-Einheitentests

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

  • Beschreiben der wichtigsten Vorteile von Apex-Einheitentests
  • Definieren einer Klasse mit Testmethoden
  • Ausführen aller Testmethoden in einer Klasse und Untersuchen von Fehlschlägen
  • Erstellen und Ausführen einer Suite mit Testklassen
Hinweis

Hinweis

Lernen Sie auf Deutsch? Beginnen Sie die Aufgabe in einem Trailhead Playground in der Sprache Deutsch und verwenden Sie für die Navigation die in Klammern angegebenen Übersetzungen. Kopieren und fügen Sie nur die Angaben in Englisch ein, da zur Überprüfung der Aufgabe Daten in Englisch benötigt werden. Wenn Sie die Aufgabe in Ihrer deutschen Organisation nicht bestehen, empfehlen wir Ihnen folgende Vorgehensweise: (1) Stellen Sie das Gebietsschema auf USA um, (2) legen Sie Englisch als Sprache fest (Anweisungen dazu finden Sie hier) und (3) klicken Sie erneut auf die Schaltfläche "Check Challenge" (Aufgabe überprüfen).

Weitere Details dazu, wie Sie die übersetzte Trailhead-Umgebung optimal nutzen können, finden Sie unter dem Badge "Trailhead in Ihrer Sprache".

Apex-Einheitentests

Mithilfe des Apex-Test-Framework können Sie für Ihre Apex-Klassen und -Auslöser Tests schreiben und ausführen. Apex-Einheitentests stellen eine hohe Qualität Ihres Apex-Codes sicher und ermöglichen Ihnen, die Anforderungen für die Bereitstellung von Apex zu erfüllen.

Tests sind der Schlüssel zu einer erfolgreichen langfristigen Entwicklung und ein wichtiger Bestandteil des Entwicklungsprozesses. Das Apex-Test-Framework bietet eine einfache Möglichkeit zum Testen Ihres Apex-Codes. Apex-Code kann nur in einer Sandbox- oder einer Entwicklerorganisation geschrieben werden, nicht jedoch in einer Produktionsorganisation. Apex-Code kann aus einer Sandbox in einer Produktionsorganisation bereitgestellt werden. Außerdem können Anwendungsentwickler Apex-Code aus ihren Entwicklerorganisationen an Kunden verteilen, indem sie Pakete auf Salesforce AgentExchange hochladen. Apex-Einheitentests sind nicht nur von entscheidender Bedeutung für die Qualitätssicherung, sondern auch Voraussetzungen für die Bereitstellung und Verteilung von Apex.

Apex-Einheitentests stellen einen Weg zu besserem Code dar. Das Apex-Test-Framework:

  • Stellt sicher, dass Ihre Apex-Klassen und -Auslöser erwartungsgemäß funktionieren.
  • Verwendet eine Abfolge von Regressionstests, die bei jeder Aktualisierung von Klassen und Auslösern erneut ausgeführt werden können, um sicherzustellen, dass zukünftige Änderungen, die Sie an Ihrer Anwendung vornehmen, bestehende Funktionen nicht beschädigen.
  • Entspricht den Anforderungen für die Codeabdeckung für die Bereitstellung von Apex in der Produktion oder Verteilung von Apex an Kunden über Pakete.
  • Stellt hochwertige Anwendungen in der Produktionsorganisation bereit, wodurch die Produktivität von Produktionsbenutzern gesteigert wird.
  • Stellt hochwertige Anwendungen für Paketabonnenten bereit, wodurch das Vertrauen Ihrer Kunden erhöht wird.

Anforderungen für die Codeabdeckung für die Bereitstellung

Bevor Sie Ihren Code bereitstellen oder für Salesforce AgentExchange als Paket erstellen können, müssen mindestens 75 % des Apex-Codes durch Tests abgedeckt sein und alle diese Tests müssen erfolgreich abgeschlossen worden sein. Zudem müssen alle Auslöser eine gewisse Abdeckung aufweisen. Codeabdeckung ist zwar eine Voraussetzung für die Bereitstellung, Sie sollten jedoch Tests nicht nur dafür schreiben, diese Voraussetzung zu erfüllen, sondern die allgemeinen Anwendungsfälle in Ihrer Anwendung testen, darunter positive und negative Testfälle sowie die Verarbeitung von mehreren oder einzelnen Datensätzen.

Syntax von Testklassen und Testmethoden

Apex-Testklassen sind mit der Anmerkung @IsTest gekennzeichnet. Testklassen können wahlweise mit den Zugriffsmodifizierern 'private' oder 'public' definiert werden. Wenn Sie eine Testklasse nur für Einheitentests verwenden, deklarieren Sie sie als privat. Öffentliche Klassen werden normalerweise für Factory-Klassen von Testdaten verwendet, was wir im Modul Erstellen von Testdaten für Apex-Tests behandeln. Klassen, die als @IsTest definiert sind, müssen Klassen der obersten Ebene darstellen.

Innerhalb der Testklasse werden Testmethoden ebenfalls mit der Annotation @IsTest definiert. Die Sichtbarkeit einer Testmethode ist nicht von Bedeutung, es spielt also keine Rolle, ob eine Testmethode als öffentlich oder privat deklariert wird, da das Test-Framework stets auf Testmethoden zugreifen kann. Aus diesem Grund enthält die Methodensyntax keine Zugriffsmodifikatoren.

Dieses Codebeispiel zeigt eine Definition einer Testklasse mit einer Testmethode.

@IsTest
private with sharing class MyTestClass {
  @IsTest static void myTest() {
    // code_block
  }
}

Die Anmerkung @IsTest kann mehrere Modifizierer innerhalb von Klammern annehmen, wobei die einzelnen Modifizierer durch ein Leerzeichen getrennt werden. Wir erörtern die Anmerkung @IsTest(seeAllData=true) kurz im Modul Erstellen von Testdaten für Apex-Tests.

Beispiel für einen Einheitentest: Test der TemperatureConverter-Klasse

Das folgende einfache Beispiel zeigt eine Testklasse mit drei Testmethoden. Die getestete Klassenmethode verwendet eine Temperaturangabe in Fahrenheit als Eingabe. Sie rechnet diese Temperatur in Celsius um und gibt das umgerechnete Ergebnis zurück. Fügen Sie die benutzerdefinierte Klasse und ihre Testklasse hinzu.

  1. Öffnen Sie Web Console (Webkonsole) über das Schnellzugriffsmenü (Setup-Zahnradsymbol).
  2. Drücken Sie in der Web Console (Webkonsole) Strg+Umschalt+P (Windows) oder ⌘+Shift+P (macOS), um die Command Palette (Befehlspalette) zu öffnen.
  3. Geben Sie SFDX: Create Apex Class (SFDX: Apex-Klasse erstellen) ein und drücken Sie die Eingabetaste.
  4. Wählen Sie als Vorlagentyp DefaultApexClass aus und drücken Sie dann die Eingabetaste.
  5. Geben Sie als Klassenname TemperatureConverter ein und drücken Sie die Eingabetaste.
  6. Wählen Sie für das Ausgabeverzeichnis force-app/main/default/classes aus und drücken Sie dann die Eingabetaste.
  7. Ersetzen Sie den Standardtext der Klasse durch Folgendes:
public with sharing class TemperatureConverter {
  // Takes a Fahrenheit temperature and returns the Celsius equivalent.
  public static Decimal FahrenheitToCelsius(Decimal fh) {
    Decimal cs = (fh - 32) * 5/9;
    return cs.setScale(2);
  }
}
  1. Um Ihre Klasse zu speichern, drücken Sie Strg+S (Windows) oder ⌘+S (macOS).
  2. Wiederholen Sie die vorherigen Schritte, um die TemperatureConverterTest-Klasse zu erstellen. Ersetzen Sie den Standardtext der Klasse durch Folgendes:
    @IsTest
    private with sharing class TemperatureConverterTest {
      @IsTest static void testWarmTemp() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(70);
        Assert.areEqual(21.11,celsius);
      }
      @IsTest static void testFreezingPoint() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(32);
        Assert.areEqual(0,celsius);
      }
      @IsTest static void testBoilingPoint() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(212);
        Assert.areEqual(100,celsius,'Boiling point temperature is not expected.');
      }
      @IsTest static void testNegativeTemp() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(-10);
        Assert.areEqual(-23.33,celsius);
      }
    }

Die Testklasse TemperatureConverterTest prüft, dass die Methode erwartungsgemäß funktioniert, indem sie sie mit unterschiedlichen Eingaben für die Temperatur in Fahrenheit aufruft. Jede Testmethode überprüft einen Eingabetyp: eine warme Temperatur, die Gefrierpunkttemperatur, die Siedepunkttemperatur und eine negative Temperatur. Die Überprüfungen erfolgen durch Aufrufen der Methode Assert.areEqual(), die zwei Parameter annimmt. Der erste Parameter ist der erwartete Wert und der zweite Parameter der Ist-Wert. Diese Methode kann darüber hinaus einen dritten Parameter annehmen, bei dem es sich um eine Zeichenfolge zur Beschreibung des durchgeführten Vergleichs handelt. Dieser optionale dritte Parameter wird im testBoilingPoint()-Beispiel verwendet. Die angegebene Zeichenfolge wird im Fall eines Assertionsfehlers protokolliert.

Aktivieren von Codeabdeckungsergebnissen

Bevor Sie Tests ausführen, aktivieren Sie die Web Console (Webkonsole), um Codeabdeckungsergebnisse abzurufen.

  1. Klicken Sie in der Web Console (Webkonsole) oben in der "Activity Bar" (Aktivitätsleiste) auf Menüsymbol.
  2. Wählen Sie File | Preferences | Settings (Datei | Voreinstellungen | Einstellungen) aus, um das Fenster "Settings" (Einstellungen) zu öffnen.
  3. Geben Sie in das Suchfeld retrieve ein.
  4. Aktivieren Sie die Einstellung Salesforcedx-vscode-apex-testing: Retrieve-test-code-coverage.
  5. Schließen Sie das Fenster.

Führen wir nun die Methoden in dieser Testklasse aus.

  1. Klicken Sie in der Web Console (Webkonsole) in der "Activity Bar" (Aktivitätsleiste) auf Testing-Symbol. Der seitliche Bereich "Testing" (Testen) wird geöffnet.
  2. Geben Sie in der Suchleiste "Testing" (Testen) TemperatureConverterTest ein.
  3. Um alle Testmethoden in der Klasse auszuführen, bewegen Sie die Maus über die Zeile TemperatureConverterTest und klicken auf Symbol "Run Test" (Test ausführen).

Im Bereich "Test Results" (Testergebnisse) werden die Ergebnisse Ihrer Tests angezeigt. Im seitlichen Bereich "Testing" (Testen) sind die Testmethoden nun mit grünen Häkchen versehen, was bedeutet, dass alle Tests bestanden wurden. Die Web Console (Webkonsole) generiert außerdem JSON- und Markdown-Dateien mit den Testergebnissen und speichert sie im Verzeichnis .sfdx/tools/testresults/apex.

Die Testergebnisse für die Klasse TemperatureConverterTest. Das Symbol des seitlichen Bereichs "Testing" (Testen), die bestandenen Testmethoden im seitlichen Bereich "Testing" (Testen), die Markdown-Datei mit Testergebnissen und der Bereich "Test Results" (Testergebnisse) sind hervorgehoben.

Nachdem Sie die Tests ausgeführt haben, wird für die Apex-Klassen und -Auslöser in der Organisation automatisch eine Codeabdeckung generiert. Sie können den Prozentsatz der Codeabdeckung in der Markdown-Datei mit Testergebnissen nachsehen. In diesem Beispiel hat die Klasse TemperatureConverter, eine Abdeckung von 100 %, wie in folgender Abbildung dargestellt.

Der prozentuale Anteil der Codeabdeckung nach Klasse in der Web Console (Webkonsole). Die Markdown-Datei mit den Testergebnissen ist hervorgehoben.

Note

Jedes Mal, wenn Sie Ihren Apex-Code ändern, führen Sie Ihre Tests erneut aus, um die Ergebnisse für die Codeabdeckung zu aktualisieren.

Zwar würde eine Testmethode bereits eine vollständige Abdeckung der TemperatureConverter-Klasse ergeben, dennoch ist es wichtig, verschiedene Eingaben zu testen, um die Qualität des Codes sicherzustellen. Es ist natürlich nicht möglich, jeden Datenpunkt zu überprüfen, doch Sie können allgemeine Datenpunkte und unterschiedliche Eingabebereiche testen. Beispielsweise können Sie die Übergabe von positiven und negativen Zahlen, Grenzwerten und ungültigen Parameterwerten testen, um negatives Verhalten zu überprüfen. Die Tests für die TemperatureConverter-Klasse überprüfen allgemeine Datenpunkte wie Gefrier- und Siedetemperatur sowie positive und negative Temperatur.

Allerdings deckt die Testklasse TemperatureConverterTest derzeit keine Grenzbedingungen oder ungültige Eingaben ab. Grenzbedingungen sind die Mindest- und Höchstwerte, die von der Methode verarbeitet werden können. Erwägen Sie zu den ungültigen Eingaben, was geschieht, wenn null als Argument an FahrenheitToCelsius() übergeben wird. Wenn die Apex-Laufzeit die Parametervariable dereferenziert, um die Formel auszuwerten, wird in diesem Fall eine System.NullPointerException ausgelöst. Zum Behandeln dieses Fehlers können Sie die FahrenheitToCelsius()-Methode so ändern, dass sie auf eine ungültige Eingabe prüft und in dem Fall null zurückgibt. Fügen Sie anschließend der TemperatureConverterTest-Klasse eine Testmethode hinzu, um das Verhalten bei ungültigen Eingaben zu überprüfen.

Bis zu diesem Punkt werden alle Tests erfolgreich abgeschlossen, da die in der Klassenmethode verwendete Umrechnungsformel korrekt ist. Das ist jedoch langweilig! Versuchen wir, einen Fehlschlag zu simulieren, um zu sehen, was passiert, wenn eine Behauptung nicht zutrifft. Ändern Sie beispielsweise den Test für die Siedepunkttemperatur und übergeben Sie einen falschen erwarteten Wert für die Siedepunkttemperatur in Celsius (0 anstelle von 100). Dies führt dazu, dass die entsprechende Testmethode fehlschlägt.

  1. Ändern Sie die Testmethode testBoilingPoint() in den folgenden Code und speichern Sie dann die aktualisierte Testklasse.
@IsTest
static void testBoilingPoint() {
  Decimal celsius = TemperatureConverter.FahrenheitToCelsius(212);
  // Simulate failure
  Assert.areEqual(0,celsius,'Boiling point temperature is not expected.');
}
  1. Führen Sie über den seitlichen Bereich "Testing" (Testen) alle Testmethoden in der Klasse TemperatureConverterTest aus. Die Behauptung in testBoilingPoint() trifft nicht zu und löst einen schwerwiegenden Fehler aus (eine "AssertException", die nicht abgefangen werden kann).
  2. Überprüfen Sie die Ergebnisse im Bereich "Test Results" (Testergebnisse). Für den Testlauf wird angegeben, dass einer von vier Tests fehlgeschlagen ist.
  3. Um die Fehlermeldung für den Testfehler zu erhalten, wählen Sie testBoilingPoint aus dem seitlichen Bereich "Testing" (Testen) aus. Die Fehlermeldung enthält den Text, den wir in der Anweisung Assert.areEqual() angegeben haben: System.AssertException: Assertion Failed: Boiling point temperature is not expected.: Expected: 0, Actual: 100.00

Die neuen Testergebnisse für die Klasse TemperatureConverterTest, bei denen die Behauptung in der Methode testBoilingPoint() fehlschlägt.

Die Testdaten in diesen Testmethoden sind Zahlen und keine Salesforce-Datensätze. Im nächsten Abschnitt erfahren Sie mehr darüber, wie Salesforce-Datensätze getestet werden und wie Sie Ihre Daten einrichten.

Erhöhen der Codeabdeckung

Versuchen Sie beim Schreiben von Tests, die höchstmögliche Codeabdeckung zu erreichen. Streben Sie nicht nur eine Abdeckung von 75 % an, also die niedrigste Abdeckung, die Salesforce für Bereitstellungen und Pakete erfordert. Je mehr Testfälle Ihre Tests abdecken, desto höher ist die Wahrscheinlichkeit, dass Ihr Code stabil ist. Selbst wenn Sie Testmethoden für alle Ihre Klassenmethoden geschrieben haben, liegt die Codeabdeckung in manchen Fällen dennoch nicht bei 100 %. Ein häufiger Grund dafür ist, dass nicht alle Datenwerte für eine bedingte Codeausführung abgedeckt werden. Manche Datenwerte werden eventuell ignoriert, wenn Ihre Klassenmethode if-Anweisungen aufweist, die dazu führen, dass unterschiedliche Zweige ausgeführt werden, je nachdem, ob die ausgewertete Bedingung erfüllt ist oder nicht. Achten Sie darauf, dass Ihre Testmethoden diese unterschiedlichen Werte berücksichtigen.

Dieses Beispiel verdeutlicht die Klassenmethode getTaskPriority(), die zwei if-Anweisungen enthält. Die Hauptaufgabe dieser Methode ist es, einen Zeichenfolgenwert für die Priorität basierend auf dem angegebenen Bundesstaat des Leads zurückzugeben. Die Methode prüft den Bundesstaat zuerst und gibt null zurück, wenn der Bundesstaat ungültig ist. Wenn der Bundesstaat "CA" lautet, gibt die Methode "High" zurück, und für alle anderen Bundesstaatenwerte gibt sie "Normal" zurück.

public with sharing class TaskUtil {
  public static String getTaskPriority(String leadState) {
    // Validate input
    if(String.isBlank(leadState) || leadState.length() > 2) {
      return null;
    }
    String taskPriority;
    if(leadState == 'CA') {
      taskPriority = 'High';
    } else {
      taskPriority = 'Normal';
    }
    return taskPriority;
  }
}
Note

Der Gleichheitsoperator (==) führt Zeichenfolgenvergleiche durch, bei denen nicht zwischen Groß- und Kleinschreibung unterschieden wird, die Zeichenfolge muss also nicht zuerst in Kleinbuchstaben umgewandelt werden. Das bedeutet, dass bei Übergabe von 'ca' oder 'Ca' die Gleichheitsbedingung mit dem Zeichenfolgenliteral 'CA' erfüllt wird.

Dies ist die Testklasse für die Methode getTaskPriority(). Die Testmethode ruft getTaskPriority() mit einem Bundesstaat (NY) auf.

@IsTest
private with sharing class TaskUtilTest {
  @IsTest
  static void testTaskPriority() {
    String pri = TaskUtil.getTaskPriority('NY');
    Assert.areEqual('Normal', pri);
  }
}

Führen Sie diese Testklasse (TaskUtilTest) in der Web Console (Webkonsole) aus und prüfen Sie die Codeabdeckung für die entsprechende TaskUtil-Klasse, die dieser Test abdeckt. Nach Abschluss des Testlaufs wird die Codeabdeckung für TaskUtil mit 75 % angezeigt.

Öffnen Sie nun die Datei TaskUtil.cls. Klicken Sie bei geöffneter Datei auf Dreistrich-Symbol am unteren Rand des Fensters von Web Console (Webkonsole), um die Einstellung Highlight Apex Code Coverage (Apex-Codeabdeckung hervorheben) zu aktivieren. Bei aktivierter Einstellung sehen Sie sechs grüne Zeilen (die abdeckten Zeilen) und zwei rote Zeilen (die nicht abdeckten Zeilen) in der Klasse TaskUtil, wie in der Abbildung gezeigt.

Abgedeckte Zeilen für die "TaskUtil"-Klasse in der Web Console (Webkonsole) Die Einstellung "Highlight Apex Code Coverage" (Apex-Codeabdeckung hervorheben) ist aktiviert.

Der Grund, warum Zeile 5 nicht abgedeckt wurde, ist, dass unsere Testklasse keinen Test für die Übergabe eines ungültigen Bundesstaatparameters enthielt. Entsprechend wurde Zeile 11 nicht abgedeckt, da die Testmethode nicht 'CA' als Bundesstaat übergab. Fügen Sie zwei weitere Testmethoden hinzu, um diese Szenarien abzudecken. Unten wird die vollständige Testklasse nach Hinzufügen der Testmethoden testTaskHighPriority() und testTaskPriorityInvalid() dargestellt. Wenn Sie diese Testklasse erneut ausführen, liegt die Codeabdeckung für TaskUtil jetzt bei 100 %.

@IsTest
private with sharing class TaskUtilTest {
  @IsTest
  static void testTaskPriority() {
    String pri = TaskUtil.getTaskPriority('NY');
    Assert.areEqual('Normal', pri);
  }
  @IsTest
  static void testTaskHighPriority() {
    String pri = TaskUtil.getTaskPriority('CA');
    Assert.areEqual('High', pri);
  }
  @IsTest
  static void testTaskPriorityInvalid() {
    String pri = TaskUtil.getTaskPriority('Montana');
    Assert.isNull(pri);
  }
}

Erstellen und Ausführen einer Testsuite

Eine Testsuite ist eine Sammlung von Apex-Testklassen, die zusammen ausgeführt werden. Erstellen Sie beispielsweise eine Suite mit Tests, die Sie immer dann ausführen, wenn Sie eine Bereitstellung vorbereiten oder Salesforce eine neue Version veröffentlicht. Richten Sie in der Developer Console eine Testsuite ein, um eine Gruppe von Testklassen zu definieren, die Sie regelmäßig zusammen ausführen.

Momentan beinhaltet Ihre Organisation zwei Testklassen. Diese zwei Klassen haben nichts miteinander zu tun, doch diese Tatsache ignorieren wir für den Augenblick einfach. Nehmen wir einmal an, es gibt Fälle, in denen Sie diese beiden Testklassen ausführen möchten, ohne sämtliche Tests in der Organisation auszuführen. In diesem Fall erstellen Sie eine Testsuite, die diese beiden Klassen enthält, und führen die Tests dann in der Suite aus.

  1. Drücken Sie in der Web Console (Webkonsole) Strg+Umschalt+P (Windows) oder ⌘+Shift+P (macOS), um die Command Palette (Befehlspalette) zu öffnen.
  2. Geben Sie SFDX: Create Apex Test Suite (SFDX: Apex-Test-Suite erstellen) ein und drücken Sie die Eingabetaste.
  3. Geben Sie TempConverterTaskUtilSuite als Name für die Suite ein und drücken Sie die Eingabetaste.
  4. Wählen Sie TaskUtilTest und TemperatureConverterTest aus und drücken Sie dann die Eingabetaste.
  5. Klicken Sie in der "Activity Bar" (Aktivitätsleiste) auf Testing-Symbol. Der seitliche Bereich "Testing" (Testen) wird geöffnet.
  6. Geben Sie in der Suchleiste "Testing" (Testen) TempConverterTaskUtilSuite ein.
  7. Um alle Tests in der Test-Suite auszuführen, bewegen Sie den Mauszeiger über die Zeile TempConverterTaskUtilSuite und klicken auf Run Test Suite-Symbol.

Erstellen von Testdaten

Salesforce-Datensätze, die in Testmethoden erstellt werden, werden nicht an die Datenbank übergeben. Sie werden per Rollback zurückgesetzt, sobald die Ausführung des Tests beendet ist. Dieses Rollback-Verhalten ist praktisch für Tests, da Sie Ihre Testdaten nach der Testausführung nicht bereinigen müssen.

Standardmäßig haben Apex-Tests keinen Zugriff auf bereits vorhandene Daten in der Organisation, mit Ausnahme von Setup- und Metadatenobjekten wie die Objekte "Benutzer" oder "Profil". Richten Sie Testdaten für Ihre Tests ein. Durch die Erstellung von Testdaten werden Ihre Tests stabiler und Fehlschläge aufgrund fehlender oder geänderter Daten in der Organisation werden vermieden. Sie können Testdaten direkt in Ihrer Testmethode oder mithilfe einer Test-Dienstprogrammklasse erstellen. Dies wird an späterer Stelle näher beschrieben.

Note

Auch wenn es keine bewährte Vorgehensweise ist, wird es Situationen geben, in denen eine Testmethode Zugriff auf bereits vorhandene Daten benötigt. Um den Zugriff auf Organisationsdaten zu ermöglichen, kennzeichnen Sie die Testmethode mit der Anmerkung @IsTest(SeeAllData=true). Die Testmethodenbeispiele in diesem Abschnitt greifen nicht auf Organisationsdaten zu und verwenden daher den Parameter SeeAllData nicht.

Weitere Infos

  • Sie können Salesforce Apex Extension for Visual Studio Code verwenden, um Apex-Tests auszuführen und die Funktionalität Ihres Codes zu überprüfen.
  • Sie können bis zu 6 MB an Apex-Code in jeder Organisation speichern. Mit der Anmerkung @IsTest gekennzeichnete Testklassen werden auf diese Obergrenze nicht angerechnet.
  • Testdaten werden zwar per Rollback zurückgesetzt, für Tests wird jedoch keine separate Datenbank verwendet. Aus diesem Grund führt das Einfügen doppelter sObject-Datensätze bei manchen sObjects, die Felder mit eindeutigen Beschränkungen aufweisen, zu einem Fehler.
  • Testmethoden senden keine E-Mails.
  • Testmethoden können keine Callouts an externe Services senden. In Tests können simulierte Callouts verwendet werden.
  • In einem Test durchgeführte SOSL-Suchvorgänge geben leere Ergebnisse zurück. Um vorhersehbare Ergebnisse zu erhalten, verwenden Sie Test.setFixedSearchResults(), um die Datensätze zu definieren, die von der Suche zurückgegeben werden sollen.

Ressourcen

Vorbereiten auf die praktische Aufgabe

Damit Sie die praktische Aufgabe am Ende dieser Lektion absolvieren können, müssen Sie eine neue Apex-Klasse namens VerifyDate erstellen. Kopieren Sie dazu den nachfolgend angegebenen Code:

public with sharing class VerifyDate {
  //method to handle potential checks against two dates
  public static Date CheckDates(Date date1, Date date2) {
    //if date2 is within the next 30 days of date1, use date2.  Otherwise use the end of the month
    if(DateWithin30Days(date1,date2)) {
      return date2;
    } else {
      return SetEndOfMonthDate(date1);
    }
  }
  //method to check if date2 is within the next 30 days of date1
  private static Boolean DateWithin30Days(Date date1, Date date2) {
    //check for date2 being in the past
    if( date2 < date1) { return false; }
    //check that date2 is within (>=) 30 days of date1
    Date date30Days = date1.addDays(30); //create a date 30 days away from date1
    if( date2 >= date30Days ) { return false; }
    else { return true; }
  }
  //method to return the end of the month of a given date
  private static Date SetEndOfMonthDate(Date date1) {
    Integer totalDays = Date.daysInMonth(date1.year(), date1.month());
    Date lastDay = Date.newInstance(date1.year(), date1.month(), totalDays);
    return lastDay;
  }
}
Teilen Sie Ihr Trailhead-Feedback über die Salesforce-Hilfe.

Wir würden uns sehr freuen, von Ihren Erfahrungen mit Trailhead zu hören: Sie können jetzt jederzeit über die Salesforce-Hilfe auf das neue Feedback-Formular zugreifen.

Weitere Infos Weiter zu "Feedback teilen"