Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Anmerkung
Im Kapitel Testen von Funktionen finden Sie eine vollständige Einführung in Techniken und bewährte Methoden für das Testen von Serverless-Lösungen.
Beim Testen der Serverless-Funktionen werden herkömmliche Testtypen und -techniken verwendet. Erwägen Sie jedoch auch das Testen der Serverless-Anwendungen als Ganzes. Cloud-basierte Tests bieten das genaueste Maß für die Qualität sowohl Ihrer Funktionen als auch Ihrer Serverless-Anwendungen.
Eine Serverless-Anwendungsarchitektur umfasst verwaltete Services, die über API-Aufrufe wichtige Anwendungsfunktionen bereitstellen. Aus diesem Grund muss Ihr Entwicklungszyklus automatisierte Tests beinhalten, die bei der Interaktion Ihrer Funktionen und Services die Funktionalität überprüfen.
Wenn Sie keine cloud-basierten Tests erstellen, können aufgrund von Unterschieden zwischen Ihrer lokalen Umgebung und der bereitgestellten Umgebung Probleme auftreten. Ihr kontinuierlicher Integrationsprozess muss Tests anhand einer Reihe von Ressourcen durchführen, die in der Cloud bereitgestellt werden, bevor Ihr Code in die nächste Bereitstellungsumgebung wie QA, Staging oder Produktion übertragen wird.
Lesen Sie diesen kurzen Leitfaden weiter, um weitere Informationen zu Teststrategien für Serverless-Anwendungen zu erhalten, oder besuchen Sie das Serverless Test Samples Repository
Für serverlose Tests werden Sie weiterhin Einheiten -, Integrations - und end-to-endTests schreiben.
-
Einheitentests — Tests, die an einem isolierten Codeblock ausgeführt werden. Zum Beispiel die Überprüfung der Geschäftslogik zur Berechnung der Bereitstellungskosten für einen bestimmten Artikel und Bestimmungsort.
-
Integrationstests — Tests, an denen zwei oder mehr Komponenten oder Dienste beteiligt sind, die interagieren, in der Regel in einer Cloud-Umgebung. Bei der Überprüfung einer Funktion werden beispielsweise Ereignisse aus einer Warteschlange verarbeitet.
-
End-to-end Tests — Tests, die das Verhalten einer gesamten Anwendung überprüfen. Stellen Sie beispielsweise sicher, dass die Infrastruktur korrekt eingerichtet ist und die Ereignisse zwischen den Services wie erwartet ablaufen, um die Bestellungen der Kunden aufzuzeichnen.
Testen Ihrer Serverless-Anwendungen
In der Regel verwenden Sie eine Mischung aus verschiedenen Ansätzen, um Ihren Serverless-Anwendungscode zu testen, einschließlich Tests in der Cloud, Tests mit Mock-Code und gelegentlich Tests mit Emulatoren.
Testen in der Cloud
Das Testen in der Cloud ist für alle Testphasen wertvoll, einschließlich Komponententests, Integrationstests und end-to-end Tests. Sie führen Tests für Code durch, der in der Cloud bereitgestellt wird und mit cloud-basierten Services interagiert. Dieser Ansatz bietet das genaueste Maß für die Qualität Ihres Codes.
Eine bequeme Möglichkeit, Ihre Lambda-Funktion in der Cloud zu debuggen, ist die Verwendung der Konsole mit einem Testereignis. Ein Testereignis ist eine JSON-Eingabe für Ihre Funktion. Wenn Ihre Funktion keine Eingabe erfordert, kann das Ereignis ein leeres JSON-Dokument ({}) sein. Die Konsole bietet Beispielereignisse für eine Vielzahl von Service-Integrationen. Nachdem Sie ein Ereignis in der Konsole erstellt haben, können Sie es mit Ihrem Team teilen, um das Testen einfacher und einheitlicher zu gestalten.
Anmerkung
Das Testen einer Funktion in der Konsole ist ein schneller Einstieg, aber die Automatisierung Ihrer Testzyklen gewährleistet die Anwendungsqualität und die Entwicklungsgeschwindigkeit.
Test-Tools
Um Ihren Entwicklungszyklus zu beschleunigen, gibt es eine Reihe von Tools und Techniken, die Sie beim Testen Ihrer Funktionen verwenden können. AWS SAM Accelerate und AWS CDK Watch Mode reduzieren beispielsweise beide die Zeit, die für die Aktualisierung von Cloud-Umgebungen benötigt wird.
Die Art und Weise, wie Sie Ihren Lambda-Funktionscode definieren, macht es einfach, Komponententests hinzuzufügen. Lambda benötigt einen öffentlichen, parameterlosen Konstruktor, um Ihre Klasse zu initialisieren. Durch die Einführung eines zweiten, internen Konstruktors haben Sie die Kontrolle über die Abhängigkeiten, die Ihre Anwendung verwendet.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function(): this(null)
{
}
internal Function(IDatabaseRepository repo)
{
this._repo = repo ?? new DatabaseRepository();
}
public async Task<APIGatewayProxyResponse> FunctionHandler(APIGatewayProxyRequest request)
{
var id = request.PathParameters["id"];
var databaseRecord = await this._repo.GetById(id);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
}
}Um einen Test für diese Funktion zu schreiben, können Sie eine neue Instance Ihrer Function-Klasse initialisieren und eine simulierte Implementierung von IDatabaseRepository übergeben. Die folgenden Beispiele verwenden XUnit, Moq und FluentAssertions, um einen einfachen Test zu schreiben, der sicherstellt, dass FunctionHandler einen 200-Statuscode zurückgibt.
using Xunit;
using Moq;
using FluentAssertions;
public class FunctionTests
{
[Fact]
public async Task TestLambdaHandler_WhenInputIsValid_ShouldReturn200StatusCode()
{
// Arrange
var mockDatabaseRepository = new Mock<IDatabaseRepository>();
var functionUnderTest = new Function(mockDatabaseRepository.Object);
// Act
var response = await functionUnderTest.FunctionHandler(new APIGatewayProxyRequest());
// Assert
response.StatusCode.Should().Be(200);
}
}Ausführlichere Beispiele, einschließlich Beispiele für asynchrone Tests, finden Sie im Repository für .NET-Testbeispiele
