Merge pull request #239 from Xronophobe/update--chapter-13-early-return

Author: Xronophobe

chapter_13_database_layer_validation.asciidoc

@@ -260,6 +260,20 @@ been passed an error variable, and if so, we do this:
 ((("form control classes (Bootstrap)")))
 Take a look at the https://getbootstrap.com/docs/5.3/forms/validation/#server-side[Bootstrap docs] for more
 info on form controls.
+footnote:[... and ignore their advice to prefer client-side validation.
+Ideally, having both server- and client-side validation is the best.
+If you can't do both, then server-side validation is the one you really can't do
+without.
+Check the
+https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist.html[OWASP checklist],
+if you are not convinced yet.
+Client-side validation will provide faster feedback on the UI, but
+https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#client-side-vs-server-side-validation[it is not a security measure.]
+Server-side validation is indispensable for handling any input
+that gets processed by the server--and it will also provide albeit slower,
+feedback for the client side.]
+
+
 // CSANAD: these are the new docs for Bootstrap, but for some reason they begin
 //         with saying "We recommend client-side validation" which is bad.
 // Client side validation is fine for faster UI aesthetics, sure. But they are
@@ -578,6 +592,45 @@ $ *git commit -am "Adjust new list view to do model validation"*
 ----
 
 
+Let's put an early return in the FT to separate
+what we got working from those that still need to be dealt with:
+
+[role="sourcecode"]
+.src/functional_tests/test_list_item_validation.py (ch13l???)
+====
+[source,python]
+----
+class ItemValidationTest(FunctionalTest):
+    def test_cannot_add_empty_list_items(self):
+        [...]
+        self.browser.find_element(By.ID, "id_new_item").send_keys(Keys.ENTER)
+        self.wait_for_row_in_list_table("1: Buy milk")
+
+        return
+        # TODO fix the remaining test scenarios
+
+        # Perversely, she now decides to submit a second blank list item
+        self.browser.find_element(By.ID, "id_new_item").send_keys(Keys.ENTER)
+        [...]
+----
+====
+
+
+We should also remind ourselves not to forget to remove this early return:
+
+
+[role="scratchpad"]
+*****
+* 'Remove hardcoded URLs from views.py'
+* 'Remove the early return from the FT'
+*****
+
+And now, we can focus on making our code a little neater.
+
+TIP: When working on a new feature, it's common to realize partway through that
+    a refactor of the application is needed. Adding an early return to the FT
+    you're currently working on allows you to perform this refactor against
+    passing FTs, even while the feature is still in progress.
 
 
 
@@ -628,6 +681,7 @@ and while we're thinking about it, there's one in 'home.html' too:
 [role="scratchpad"]
 *****
 * 'Remove hardcoded URLs from views.py'
+* 'Remove the early return from the FT'
 * 'Remove hardcoded URL from forms in list.html and home.html'
 *****
 
@@ -777,29 +831,21 @@ urlpatterns = [
 ----
 ====
 
-And that gets us to the `OK`.
+And that gets us to the green on the unit tests.
 
 ----
 OK
 ----
 
 
-Let's try a full FT run:
+Let's try a full FT run: they're all passing!
 
-
-[subs="specialcharacters,quotes"]
 ----
-$ *python src/manage.py test functional_tests*
-[...]
-ERROR: test_cannot_add_empty_list_items (functional_tests.test_list_item_valida
-tion.ItemValidationTest.test_cannot_add_empty_list_items)
-[...]
+Ran 4 tests in 20 s
 
-Ran 4 tests in 15.276s
-FAILED (errors=1)
+OK
 ----
 
-We're back to the one failure in our new functional test.
 Our refactor of the `add_item` functionality is complete.
 We should commit there:
 
@@ -808,16 +854,33 @@ We should commit there:
 $ *git commit -am "Refactor list view to handle new item POSTs"*
 ----
 
-NOTE: So did I break the rule about never refactoring against failing tests?
-    In this case, it's allowed, because the refactor is required
-    to get our new functionality to work.
-    You should definitely never refactor against failing _unit_ tests.
-    But in my book it's OK for the FT for the current story you're working on
-    to be failing.footnote:[
-    If you really want a "clean" test run, you could add a skip or an early return
-    to the current FT, but you'd need to make sure you didn't accidentally forget it.]
+
+We can remove the early return
+now.
+
+[role="scratchpad"]
+*****
+* 'Remove hardcoded URLs from views.py'
+* '[strikethrough line-through]#Remove the early return from the FT#'
+* 'Remove hardcoded URL from forms in list.html and home.html'
+*****
+
+Run the FTs again to see what's still there that needs to be fixed:
 
 
+[subs="specialcharacters,quotes"]
+----
+$ *python src/manage.py test functional_tests*
+[...]
+ERROR: test_cannot_add_empty_list_items (functional_tests.test_list_item_valida
+tion.ItemValidationTest.test_cannot_add_empty_list_items)
+[...]
+
+Ran 4 tests in 15.276s
+FAILED (errors=1)
+----
+
+We're back to the one failure in our new functional test.
 
 
 
@@ -901,6 +964,7 @@ We'll just add it to our scratchpad for now:
 [role="scratchpad"]
 *****
 * 'Remove hardcoded URLs from views.py'
+* '[strikethrough line-through]#Remove the early return from the FT#'
 * 'Remove hardcoded URL from forms in list.html and home.html'
 * 'Remove duplication of validation logic in views'
 *****
@@ -1015,6 +1079,7 @@ $ *git commit -am "Refactor hard-coded URLs out of templates"*
 [role="scratchpad"]
 *****
 * 'Remove hardcoded URLs from views.py'
+* '[strikethrough line-through]#Remove the early return from the FT#'
 * '[strikethrough line-through]#Remove hardcoded URL from forms in list.html and home.html#'
 * 'Remove duplication of validation logic in views'
 *****
@@ -1148,6 +1213,7 @@ Cross off our to-dos...
 [role="scratchpad"]
 *****
 * '[strikethrough line-through]#Remove hardcoded URLs from views.py#'
+* '[strikethrough line-through]#Remove the early return from the FT#'
 * '[strikethrough line-through]#Remove hardcoded URL from forms in list.html and home.html#'
 * 'Remove duplication of validation logic in views'
 *****