first part of review remakrs

Author: kpotzahr

modules/ROOT/pages/cross_cutting/test_automation/architecture_tests.adoc

@@ -12,7 +12,7 @@ Naming convention test::
 +
 --
 [source, java]
-@AnalyzeClasses(packages = "com.capgemini.component")
+@AnalyzeClasses(packages = "com.myapp.component")
 public class NamingRuleTest {
     @ArchTest
     static ArchRule entities_named_correctly =
@@ -32,7 +32,7 @@ Layered Architecture Test::
 --
 [source, java]
 
-@AnalyzeClasses(packages = "com.capgemini.component")
+@AnalyzeClasses(packages = "com.myapp.component")
 public class DependencyRuleTest {
     @ArchTest
     static ArchRule layered_architecture_check =

modules/ROOT/pages/cross_cutting/test_automation/sub_system_tests.adoc

@@ -292,6 +292,7 @@ Web development often works with libraries or patterns of re-usable UI component
 They change over time.  
 Like the motivation for the page object pattern, you don't want to change all tests or all page objects, if the internal structure of such a component changes. 
 So, similar to page objects, create "widget objects" that encapsulate the access to common UI components.
+These widget objects are then used in page objects.
 
 If you use Selenium, you need to expect https://www.baeldung.com/selenium-staleelementreferenceexception[StaleElementReferenceExceptions].
 So, you should not save a reference to a WebElement in your widget object.

modules/ROOT/pages/cross_cutting/test_automation/test_automation.adoc

@@ -14,7 +14,7 @@ not more than one class;
 all other classes mocked; 
 especially no access to database.
 * *(Unit-Integration-Tests)*: 
-closely rated units are tested together;
+closely related units are tested together;
 outside scope mocked;
 no access to database; 
 often not considered as an extra level, but as part of Unit-Tests.

modules/ROOT/pages/cross_cutting/test_automation/unit_tests.adoc

@@ -5,7 +5,7 @@ This articles focuses on Unit- and Unit-Integration-Tests.
 General test automation good practices can be found xref:cross_cutting/test_automation/test_automation.adoc[here].
 
 === Use TDD to improve code and test quality
-https://testdriven.io/test-driven-development/[Test Driven Development (TDD)] is a software development method where tests are written first before the actual code.
+https://testdriven.io/test-driven-development/[Test Driven Development (TDD)] is a software development method where tests are written first before the actual code in cycles "make it red, make it green, make it clean".
 It leads to better tests and often to a better design, because the parts where the logic happens are better structured to allow easy testing.
 It also leads to better code, because the last step is a refactoring that can be performed safely because of the tests.