开云体育

On Tue, Mar 29, 2022 at 5:31 PM Russell Gold <russ@...> wrote: > > > On Mar 29, 2022, at 2:58 PM, J. B. Rainsberger <me@...> wrote: > > On Tue, Mar 29, 2022 at 1:57 PM Russell Gold

I realized later that you might have meant this. I don't use the words this way, so I didn't grasp the difference immediately. IntelliJ IDEA, for example, doesn't assume that "inline" means

If that’s your situation, your first step must be to figure out a how to run a segment of your program through a Saff loop before your can even consider applying the technique. In my case, it might

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

Thanks all more clear now. We want to do a copy/paste inline. The difference being that the IDE will delete the original function when inlining, not make an inlined copy.

That's _exactly_ what the Saff Squeeze does: it starts with a failing, bigger unit test and produces a missing, smaller unit test. It merely uncovers that test systematically instead of relying on

I'm surprised by this framing. I don't know what the Saff Squeeze has to do with experience with TDD. The Squeeze doesn't care whether you've written the test first nor whether you're doing

[email protected]> wrote:

What's the difference? -- J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca <https://www.jbrains.ca> :: blog.thecodewhisperer.com

You're deleting code from the test as you inline parts of the test. You're only changing production code in order to make the test work (making non-public parts public, mostly). -- J. B. (Joe)

I’ve never heard of the “Mikado method,” but that’s pretty much the way I learned to do TDD. Saff’s technique seems interesting, and I will keep it in mind for the future; I’m not sure

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.

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

Hi Alan, [email protected]> wrote: I see how this can be confusing. The difference is in case A you don't simply "delete" commits, "squashing" means you replace several commits with a single

I'm confused by language in that post.? I think "commit" means locally post to Source control your newly changed code.?? Then we see this: - > A) Maybe squash all these commits, because they add

Copy/paste inline, or actually inline?

It's in the tests, because you start with inlining the code tested in the failing test. IIUC everything happens in the tests, until you get to the point where you uncover that "missing test" JB is

Very nice, but one piece confuses me. Am I supposed to delete if statements in the production code, or if statements in the tests? Also, can this help with bugs related to third party libraries?

I simply haven't published it yet. And that's funny, because I've been doing it _often_ the past few days. I finally published something about it. Let's see how the world