From 6b36020fae1c2e5119429bd00340b21086bebeee Mon Sep 17 00:00:00 2001
From: Gleb Moskalenko <66567192+glebmxyz@users.noreply.github.com>
Date: Mon, 12 Sep 2022 14:17:53 +0300
Subject: [PATCH] Fix typo in testing/choosing-a-testing-strategy.md

Remove extra article
---
 entity-framework/core/testing/choosing-a-testing-strategy.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/entity-framework/core/testing/choosing-a-testing-strategy.md b/entity-framework/core/testing/choosing-a-testing-strategy.md
index ca88f9932e..dc96c3d8fa 100644
--- a/entity-framework/core/testing/choosing-a-testing-strategy.md
+++ b/entity-framework/core/testing/choosing-a-testing-strategy.md
@@ -40,7 +40,7 @@ Below, we'll explore what each method means, and compare it with the others. We
 
 ### SQLite as a database fake
 
-One possible testing approach is to swap your production database (e.g. SQL Server) with SQLite, effectively using it as a testing "fake". Aside from ease of setup, SQLite has a an [in-memory database](https://sqlite.org/inmemorydb.html) feature which is especially useful for testing: each test is naturally isolated in its own in-memory database, and no actual files need to be managed.
+One possible testing approach is to swap your production database (e.g. SQL Server) with SQLite, effectively using it as a testing "fake". Aside from ease of setup, SQLite has an [in-memory database](https://sqlite.org/inmemorydb.html) feature which is especially useful for testing: each test is naturally isolated in its own in-memory database, and no actual files need to be managed.
 
 However, before doing this, it's important to understand that in EF Core, different database providers behave differently - EF Core does not attempt to abstract every aspect of the underlying database system. Fundamentally, this means that testing against SQLite does not guarantee the same results as against SQL Server, or any other database. Here are some examples of possible behavioral differences: