วีดีโอ

TCR test && commit || revert is an alternative programming workflow similar to TDD. Run the tests after every change. If they pass, commit. If they fail, revert to the last passing state. As you'll see, this means that changes that don't work just *poof* disappear. Putting changes at risk creates a powerful incentive to make changes in teensy tiny steps. In this episode we "make it right", givi...

TCR test && commit || revert is an alternative programming workflow similar to TDD. Run the tests after every change. If they pass, commit. If they fail, revert to the last passing state. As you'll see, this means that changes that don't work just *poof* disappear. Putting changes at risk creates a powerful incentive to make changes in teensy tiny steps. In this episode we finish the "make it r...

In which I use runOnSave to trigger the TCR cycle in the cheapest, ugliest way possible. Small investment and low latency is good.

TCR test && commit || revert is an alternative programming workflow similar to TDD. Run the tests after every change. If they pass, commit. If they fail, revert to the last passing state. As you'll see, this means that changes that don't work just *poof* disappear. Putting changes at risk creates a powerful incentive to make changes in teensy tiny steps.

And finally, tests are a way to liberate energy, to move from worry to hope, creativity, and empathy, to demonstrate trustworthiness. Passing tests should feel good. If your tests don't inspire, then you may be making tradeoffs you don't need to make. Which is the topic of our final, final bonus episode. You can watch the other videos in the Test Desiderata playlist: th-cam.com/play/PLlmVY7qtgT...

Imagine you had an oracle that would predict with 100% accuracy whether a change was fit for production. Pretty cool, eh? How about 99%? Still pretty cool. You can watch the other videos in the Test Desiderata playlist: th-cam.com/play/PLlmVY7qtgT_lkbrk9iZNizp978mVzpBKl.html Read the original post: medium.com/@kentbeck_7670/test-desiderata-94150638a4b3 Episodes in this series are released every...

When a test fails you save minutes/hours/days of debugging if the failure points to a specific problem. You can watch the other videos in the Test Desiderata playlist: th-cam.com/play/PLlmVY7qtgT_lkbrk9iZNizp978mVzpBKl.html Read the original post: medium.com/@kentbeck_7670/test-desiderata-94150638a4b3 Episodes in this series are released every Thursday at 9am PT. Unless we forget.

You can't test all combinations of inputs. How, then, can you be confident your code works? The confidence provided by one test should combine with the confidence provided by other tests. There is a subtle art to this, and also a step of inductive reasoning, but once you master composing tests you can test at much smaller cost. You can watch the other videos in the Test Desiderata playlist: th-...

Whether one test passes or not should have no effect on whether another test passes. You can ensure this by either: 1. Only using locally initialized state or 2. Returning the world to exactly its previous state after running each test This creates tradeoffs with other desiderata, like writability and speed. You can watch the other videos in the Test Desiderata playlist: th-cam.com/play/PLlmVY7...

You can get feedback immediately by running the code you just changed and looking at the results. However, the confidence you gain evaporates the moment you change anything else (or it should). Automating tests gives you confidence any time you need it at the touch of a button. The cost of automating tests is the software design effort necessary to have a clear interface against which to test. ...

Me: This test failed. Them: Run it again. If it passes, deploy. Me: If nothing changes, then nothing should change, especially test results. It's easy to write tests that sometimes run and sometimes don't, though, as we illustrate from recent Gusto history. You can watch the other videos in the Test Desiderata playlist: th-cam.com/play/PLlmVY7qtgT_lkbrk9iZNizp978mVzpBKl.html Read the original p...

Do you lose concentration while waiting for test feedback? The speed of feedback is a key property navigating the trade offs in test writing. Perfect feedback that takes so long to that you don’t wait for it doesn’t help. Nor does instantly being delivered feedback that doesn’t predict the behavior of code in production. Where in between should you land? You can watch the other videos in the Te...

If you want to improve a business, where do you look for information? Here are four possibilities: * Effort * Output * Outcome * Impact In the next video we'll describe the tradeoffs between these observations. Also, this is an experiment in a Memoji style of presentation. Let me know what you think in the comments.

If I can't test it, I designed it wrong. Whether tests are easy to write is a property of the design of the code, not of the tests. When we find it difficult to write tests, what does that tell us about our design? How can we improve our design to make it easier to write tests? If we can call it from tests, others can call the code in production. You can watch the other videos in the Test Desid...

Test Desiderata 3/12 Readable

Test Desiderata 2/12 Tests Should be Structure-Insensitive

Test Desiderata 1/12 Behavior

Understanding Legacy Code with TCR (test && commit || revert)

TCR in VS Code

substring, TCR style

Puppies Bite

The Return of the Waterfall

Puppy singalong

Making Making CoffeeScript

Kent Beck Geeky Standup Comedy Set

First 10 minutes of TDD intro episode 1 (unedited)