The refactoring is slow right now - seriously I need more test cases in place before I do the next stage.
This way, if I make a mistake, I'll know it first hand.
I just found one bug that needs to be fixed for making the code testable. Yay.
Almost through the flow
Just have to explore the cases of accepting/denying and checking if that logic works or not for pass/fail cases.
Then. And only then, can the next round of functional improvements can begin.
It's all good.
Yikes! Failures! But to be honest, this is a good thing. When testing, failures means that something needs to be fixed.
Instead of just letting a system die, it's time to fix things. Otherwise, it's just giving up or what we used to call: Windows 3.0.
Yes, there is a reference to Tidy Bowl. Product Function: It uses blue or lavender liquids and tablets placed inside the toilet tank to fight hard water stains, mineral buildup, and ring formation between regular scrubbings. It was also marketed as Ty-D-Bol (sounds like the topic for a podcast).
I use it as my example of a job that I would not be good at:
Company: TidyBowl (avoids messy trademarking stuff)
Role: Taste Tester
Job Description: Must have excellent taste testing skills. A sommelier for boxed wine.
This job, like boxed wines does not pair well with my skills, typically earning a 0 score, and None for a created cover letter. A zero score should also invalidate the button to produce output. The only option is to return to the system.
The 3 errors were introduced with some changes to the selenium (automated UI) tests. The fourth is a dangling error from earlier that is proving to be annoying to fix at this time.
Much better
![]()
The fix was simple: a breakpoint() call while I was debugging the verbosity field coming back in the request.form. Done and dusted - back to coding the flow tests and the actual flow code.
No comments:
Post a Comment