To be clear, I am the original poster; I have plenty of experience with TDD but minimal experience with Asynchronous web-based testing. ?Everything I tested before now was a function call that does a bunch of stuff and gives me [access to] values I can assert against. ?I was merely lost how to get past the web-portal login for testing my use of external API¡¯s. ?That question has largely been resolved in my mind. ?(For now.)
toggle quoted message
Show quoted text
On Mar 29, 2022, at 12:29, Steve Gordon <sgordonphd@...> wrote:
?
Given the original question where the poster is catching up with his legacy code, which implies no experience doing TDD, the Saff's technique seems to be overkill that discourages getting started.? Keep it simple until enough experience?is gained to warrant getting more sophisticated.
On Tue, Mar 29, 2022 at 9:16 AM Alan Baljeu via <alanbaljeu=
[email protected]> wrote:
This looks like a useful method.? Another approach I learned as the Mikado method:?
1. Write a failing test.
2. Change the code to pass it.
3. If you can't _simply_ do this, then:
a. identify where you get stuck
b. revert
c. refactor so you're not stuck, and goto 1 (or 2).
In the context to match Saff's technique, the refactoring would slowly expose the heart of the troublesome code until the problem is identified and solved.? That said, I can see Saff's route may be more efficient at times.? It especially looks useful if the problem ultimately lies in a 3rd party's library and you need to send a small failing test for them to fix your problem.
