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.

# AWS Lambda Funktionstests in C\#
<a name="dotnet-csharp-testing"></a>

**Anmerkung**  
Im Kapitel [Testen von Funktionen](testing-guide.md) finden Sie eine vollständige Einführung in Techniken und bewährte Methoden für das Testen von Serverless-Lösungen. 

 Beim Testen serverloser Funktionen werden herkömmliche Testtypen und -techniken verwendet. Sie müssen jedoch auch in Betracht ziehen, serverlose Anwendungen als Ganzes zu testen. Cloud-based Tests bieten das **genaueste** Maß für die Qualität Ihrer Funktionen und serverlosen 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](https://github.com/aws-samples/serverless-test-samples), um praktische Beispiele zu finden, die sich speziell auf die gewählte Sprache und Laufzeit beziehen. 

 ![illustration showing the relationship between types of tests](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/test-type-illustration2.png) 

 Für Serverless-Tests schreiben Sie weiterhin *Einheiten*-, *Integrations*- und *End-to-End*-Tests. 
+ **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
<a name="dotnet-csharp-testing-techniques-for-serverless-applications"></a>

 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
<a name="dotnet-csharp-testing-in-the-cloud"></a>

 Das Testen in der Cloud ist für alle Testphasen von Nutzen, einschließlich Einheitentests, 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](testing-functions.md) ist ein schneller Einstieg, aber die Automatisierung Ihrer Testzyklen gewährleistet die Anwendungsqualität und die Entwicklungsgeschwindigkeit. 

### Test-Tools
<a name="dotnet-csharp-testing-tools"></a>

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](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-sync.html) und [AWS CDK Watch Mode](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-watch) 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](https://github.com/aws-samples/serverless-test-samples/tree/main/dotnet-test-samples) unter GitHub.