Revert changes on new lines

Author: bubafinder

recipes/automated-testing.md

@@ -1,47 +1,28 @@
 # Automated Testing
 ## Glossary
-**Confidence** - describes a degree to which passing tests guarantee that the
-app is working.  
-**Determinism** - describes how easy it is to determine where the problem is
-based on the failing test.  
-**Use Case** - a potential scenario in which a system receives external input
-and responds to it. It defines the interactions between a role (user or another
-system) and a system to achieve a goal.  
-**Combinatiorial Explosion** - the fast growth in the number of combinations
-that need to be tested when multiple business rules are involved.  
+**Confidence** - describes a degree to which passing tests guarantee that the app is working.  
+**Determinism** - describes how easy it is to determine where the problem is based on the failing test.  
+**Use Case** - a potential scenario in which a system receives external input and responds to it. It defines the interactions between a role (user or another system) and a system to achieve a goal.  
+**Combinatiorial Explosion** - the fast growth in the number of combinations that need to be tested when multiple business rules are involved.  
 
 ## Testing best practices
 
 ### Quality over quantity
 Don't focus on achieving a specific code coverage percentage.
-While code coverage can help us identify uncovered parts of the codebase, it
-doesn't guarantee high confidence.
+While code coverage can help us identify uncovered parts of the codebase, it doesn't guarantee high confidence.
 
-Instead, focus on identifying important paths of the application, especially
-from user's perspective.
-User can be a developer using a shared function, a user interacting with the UI,
-or a client using server app's JSON API.
-Write tests to cover those paths in a way that gives confidence that each path,
-and each separate part of the path works as expected.
+Instead, focus on identifying important paths of the application, especially from user's perspective.
+User can be a developer using a shared function, a user interacting with the UI, or a client using server app's JSON API.
+Write tests to cover those paths in a way that gives confidence that each path, and each separate part of the path works as expected.
 
 ---
 
-Flaky tests that produce inconsistent results ruin confidence in the test suite,
-mask real issues, and are the source of frustration. The refactoring process to
-address the flakiness is crucial and should be a priority.
-To adequately deal with flaky tests it is important to know how to identify,
-fix, and prevent them:
-- Common characteristics of flaky tests include inconsistency, false positives
-and negatives, and sensitivity to dependency, timing, ordering, and environment.
-- Typical causes of the stated characteristics are concurrency, timing/ordering
-problems, external dependencies, non-deterministic assertions, test environment
-instability, and poorly written test logic.
-- Detecting flaky tests can be achieved by rerunning, running tests in parallel,
-executing in different environments, and analyzing test results.
-- To fix and prevent further occurrences of flaky tests the following steps can
-be taken, isolate tests, employ setup and cleanup routines, handle concurrency,
-configure a stable test environment, improve error handling, simplify testing
-logic, and proactively deal with typical causes of the flaky tests.
+Flaky tests that produce inconsistent results ruin confidence in the test suite, mask real issues, and are the source of frustration. The refactoring process to address the flakiness is crucial and should be a priority.
+To adequately deal with flaky tests it is important to know how to identify, fix, and prevent them:
+- Common characteristics of flaky tests include inconsistency, false positives and negatives, and sensitivity to dependency, timing, ordering, and environment.
+- Typical causes of the stated characteristics are concurrency, timing/ordering problems, external dependencies, non-deterministic assertions, test environment instability, and poorly written test logic.
+- Detecting flaky tests can be achieved by rerunning, running tests in parallel, executing in different environments, and analyzing test results.
+- To fix and prevent further occurrences of flaky tests the following steps can be taken, isolate tests, employ setup and cleanup routines, handle concurrency, configure a stable test environment, improve error handling, simplify testing logic, and proactively deal with typical causes of the flaky tests.
 
 ---
 
@@ -93,25 +74,19 @@ It is convenient to test a specific function at the lowest level so if the logic
 changes, we can make minimal changes to the test suite and/or mocked data.
 
 #### When to use
-- Test a unit that implements the business logic, that's isolated from side
-effects such as database interaction or HTTP request processing
+- Test a unit that implements the business logic, that's isolated from side effects such as database interaction or HTTP request processing
 - Test function or class method with multiple input-output permutations
 
 #### When **not** to use
-- To test unit that integrates different application layers, such as persistence
-layer (database) or HTTP layer (see "Integration Tests") or performs disk I/O or
-communicates with external system
+- To test unit that integrates different application layers, such as persistence layer (database) or HTTP layer (see "Integration Tests") or performs disk I/O or communicates with external system
 
 #### Best practices
 - Unit tests should execute fast (<50ms)
 - Use mocks and stubs through dependency injection (method or constructor injection)
 
 #### Antipatterns
-- Mocking infrastructure parts such as database I/O - instead, revert the
-control by using the `AppService`, `Command` or `Query` to integrate unit
-implementing business logic with the infrastructure layer of the application
-- Monkey-patching dependencies used by the unit - instead, pass the dependencies
-through the constructor or method, so that you can pass the mocks or stubs in the test
+- Mocking infrastructure parts such as database I/O - instead, revert the control by using the `AppService`, `Command` or `Query` to integrate unit implementing business logic with the infrastructure layer of the application
+- Monkey-patching dependencies used by the unit - instead, pass the dependencies through the constructor or method, so that you can pass the mocks or stubs in the test
 
 
 ### Integration Tests
@@ -120,36 +95,20 @@ With these tests, we test how multiple components of the system behave together.
 
 #### Infrastructure
 
-Running the tests on test infrastructure should be preferred to mocking, unlike
-in unit tests. Ideally, a full application instance would be run, to mimic real
-application behavior as close as possible.
-This usually includes running the application connected to a test database,
-inserting fake data into it during the test setup, and doing assertions on the
-current state of the database. This also means integration test code should have
-full access to the test infrastructure for querying. 
+Running the tests on test infrastructure should be preferred to mocking, unlike in unit tests. Ideally, a full application instance would be run, to mimic real application behavior as close as possible.
+This usually includes running the application connected to a test database, inserting fake data into it during the test setup, and doing assertions on the current state of the database. This also means integration test code should have full access to the test infrastructure for querying. 
 > [!NOTE]
-> Regardless of whether using raw queries or the ORM, simple queries should be
-> used to avoid introducing business logic within tests.
+> Regardless of whether using raw queries or the ORM, simple queries should be used to avoid introducing business logic within tests.
 
-However, mocking can still be used when needed, for example when expecting
-side-effects that call third party services.
+However, mocking can still be used when needed, for example when expecting side-effects that call third party services.
 
 #### Entry points
 
-Integration test entry points can vary depending on the application use cases.
-These include services, controllers, or the API. These are not set in stone and
-should be taken into account when making a decision. For example:
-- A use case that can be invoked through multiple different protocols can be
-tested separately from them, to avoid duplication. A tradeoff in this case is
-the need to write some basic tests for each of the protocols.
-- A use case that will always be invokeable through a single protocol might
-benefit enough from only being tested using that protocol. E.g. a HTTP API route
-test might eliminate the need for a lower level, controller/service level test.
-This would also enable testing the auth layer integration within these tests,
-which might not have been possible otherwise depending on the technology used.
-
-Multiple approaches can be used within the same application depending on the
-requirements, to provide sufficient coverage.
+Integration test entry points can vary depending on the application use cases. These include services, controllers, or the API. These are not set in stone and should be taken into account when making a decision. For example:
+- A use case that can be invoked through multiple different protocols can be tested separately from them, to avoid duplication. A tradeoff in this case is the need to write some basic tests for each of the protocols.
+- A use case that will always be invokeable through a single protocol might benefit enough from only being tested using that protocol. E.g. a HTTP API route test might eliminate the need for a lower level, controller/service level test. This would also enable testing the auth layer integration within these tests, which might not have been possible otherwise depending on the technology used.
+
+Multiple approaches can be used within the same application depending on the requirements, to provide sufficient coverage.
 
 #### Testing surface
 
@@ -173,16 +132,11 @@ time decoupling logic testing and endpoint testing.
 - To verify the API endpoint performs authentication and authorization.
 - To verify user permissions for that endpoint.
 - To verify that invalid input is correctly handled.
-- To verify the basic business logic is handled correctly, both in expected
-success and failure cases.
-- To verify infrastructure related side-effects, e.g. database changes or calls
-to third party services.
+- To verify the basic business logic is handled correctly, both in expected success and failure cases.
+- To verify infrastructure related side-effects, e.g. database changes or calls to third party services.
 
 #### When **not** to use
-- For extensive testing of business logic permutations beyond fundamental
-scenarios. Integration tests contain more overhead to write compared to unit
-tests and can easily lead to a combinatorial explosion. Instead, unit tests
-should be used for thorough coverage of these permutations.
+- For extensive testing of business logic permutations beyond fundamental scenarios. Integration tests contain more overhead to write compared to unit tests and can easily lead to a combinatorial explosion. Instead, unit tests should be used for thorough coverage of these permutations.
 - For testing third party services. We should assume they work as expected.
 
 #### Best practices
@@ -203,16 +157,10 @@ returns the expected data. That means we write tests for the publically
 available endpoints.
 
 > [!NOTE]
-> As mentioned in the Integration Tests section, API can be the entry point to
-> the integration tests, meaning API tests are a subtype of integration tests.
-> However, when we talk about API tests here, we are specifically referring to
-> the public API contract tests, which don't have access to the internals of
-> the application.
-
-In the cases where API routes are covered extensively with integration tests,
-API tests might not be needed, leaving more time for QA to focus on E2E tests.
-However, in more complex architectures (e.g. integration tested microservices
-behind an API gateway), API tests can be very useful.
+> As mentioned in the Integration Tests section, API can be the entry point to the integration tests, meaning API tests are a subtype of integration tests. However, when we talk about API tests here, we are specifically referring to the public API contract tests, which don't have access to the internals of the application.
+
+In the cases where API routes are covered extensively with integration tests, API tests might not be needed, leaving more time for QA to focus on E2E tests.
+However, in more complex architectures (e.g. integration tested microservices behind an API gateway), API tests can be very useful.
 
 #### When to use
 - To make sure the API signature is valid.