🔧 Update config with new pymdown extensions (#712)

* 🔧 Update config with new pymdown extensions

* 📝 Update admonition blocks syntax

* 📝 Update syntax for tabs with new pymdown extensions

docs/tutorial/fastapi/tests.md

@@ -71,8 +71,11 @@ Let's start with a simple test, with just the basic test code we need the check
 
 {!./docs_src/tutorial/fastapi/app_testing/tutorial001/annotations/en/test_main_001.md!}
 
-!!! tip
-    Check out the number bubbles to see what is done by each line of code.
+/// tip
+
+Check out the number bubbles to see what is done by each line of code.
+
+///
 
 That's the **core** of the code we need for all the tests later.
 
@@ -116,8 +119,11 @@ That way we protect the production database and we have better control of the da
 
 {!./docs_src/tutorial/fastapi/app_testing/tutorial001/annotations/en/test_main_002.md!}
 
-!!! tip
-    Check out the number bubbles to see what is done by each line of code.
+/// tip
+
+Check out the number bubbles to see what is done by each line of code.
+
+///
 
 ## Create the Engine and Session for Testing
 
@@ -197,8 +203,11 @@ We just have to change a couple of parameters in the **engine**.
 
 {!./docs_src/tutorial/fastapi/app_testing/tutorial001/annotations/en/test_main_004.md!}
 
-!!! tip
-    Check out the number bubbles to see what is done by each line of code.
+/// tip
+
+Check out the number bubbles to see what is done by each line of code.
+
+///
 
 That's it, now the test will run using the **in-memory database**, which will be faster and probably safer.
 
@@ -214,8 +223,11 @@ Do we really have to duplicate all that for **each test**? No, we can do better!
 
 We are using **pytest** to run the tests. And pytest also has a very similar concept to the **dependencies in FastAPI**.
 
-!!! info
-    In fact, pytest was one of the things that inspired the design of the dependencies in FastAPI.
+/// info
+
+In fact, pytest was one of the things that inspired the design of the dependencies in FastAPI.
+
+///
 
 It's a way for us to declare some **code that should be run before** each test and **provide a value** for the test function (that's pretty much the same as FastAPI dependencies).
 
@@ -237,8 +249,11 @@ Let's see the first code example with a fixture:
 
 {!./docs_src/tutorial/fastapi/app_testing/tutorial001/annotations/en/test_main_005.md!}
 
-!!! tip
-    Check out the number bubbles to see what is done by each line of code.
+/// tip
+
+Check out the number bubbles to see what is done by each line of code.
+
+///
 
 **pytest** fixtures work in a very similar way to FastAPI dependencies, but have some minor differences:
 
@@ -274,8 +289,11 @@ So, we can create a **client fixture** that will be used in all the tests, and i
 
 {!./docs_src/tutorial/fastapi/app_testing/tutorial001/annotations/en/test_main_006.md!}
 
-!!! tip
-    Check out the number bubbles to see what is done by each line of code.
+/// tip
+
+Check out the number bubbles to see what is done by each line of code.
+
+///
 
 Now we have a **client fixture** that, in turn, uses the **session fixture**.
 
@@ -306,10 +324,13 @@ Let's add some more tests:
 
 </details>
 
-!!! tip
-    It's always **good idea** to not only test the normal case, but also that **invalid data**, **errors**, and **corner cases** are handled correctly.
+/// tip
 
-    That's why we add these two extra tests here.
+It's always **good idea** to not only test the normal case, but also that **invalid data**, **errors**, and **corner cases** are handled correctly.
+
+That's why we add these two extra tests here.
+
+///
 
 Now, any additional test functions can be as **simple** as the first one, they just have to **declare the `client` parameter** to get the `TestClient` **fixture** with all the database stuff setup. Nice! 😎