Tweet

This Thread may be Removed Anytime!

Twitter may remove this content at anytime! Save it as PDF for later use!

More from @RonJeffries

Ron Jeffries

@RonJeffries

9 May

I have what seems to me to be an "interesting" problem in my long-running Dungeon series. A dungeon is an array of tiles. Randomly placed in the array are rectangular rooms.

1/8

Rooms are connected from room N to room N-1 by halls from center to center, either first H then V or first V then H. This means that a given all way can cut through any other room, two halls can be side by side, making a wide hallway, and so on.

2/8

Like this:

Complex map in top right of dungeon picture.

3/8

Read 10 tweets

Ron Jeffries

@RonJeffries

18 Mar

What matters?

Could we maybe stop fomenting hatred?
Could we maybe start calling it out as wring?

1/2

What doesn't matter?

Dungeon 124
I want to get a creature to lead us to the WayDown. And I feel the need to improve the campground. Also St. Gertude. And, as often happens, we don't go where I expect. Neat outcome, though
ronjeffries.com/articles/020-d…

2/2

Yes, I see a typo. Will fix. If you see two different ones, let me know.

3/2

Read 4 tweets

Ron Jeffries

@RonJeffries

21 Feb 20

while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve.

Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.

XP doesn't really contemplate separate testing. Like Scrum, at the end of the iteration, the "programmers" deliver a working tested integrated version of the product. N.B. tested.

Read 12 tweets

Ron Jeffries

@RonJeffries

22 Jan 20

The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9

As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9

You're supposed to look up when the rumble strip rumbles, and think about how you got off the road. You're supposed to survive hitting the guard rail, to think about maybe slowing down for curves.

3/9

Read 9 tweets

Ron Jeffries

@RonJeffries

18 Jan 20

OK, strong article to follow but for now, listen up.
There's this idea, the red/green/refactor thing, the never write a line of code not required by a failing test thing, the evolve the design based on the test and code plus your lovely imagination thing, the keep it clean thing.

I say "idea". You can see many ideas there already.

There is a name, TDD, Test-Driven Development or Test-Driven Design, that is applied to that bunch of ideas. We want to draw a bright line around the ideas that /are/ TDD, and to keep out the ones that are not TDD.

Yeah, no, we can't do that. Ideas are mushy and they flow one into another and they smear all over each other, and they change from something sensible to something stupid right before your eyes.

Still, we'd like to do that and for now I'll try to do that.

Read 19 tweets

Ron Jeffries

@RonJeffries

31 Dec 19

@jcoplien

I'm writing a thing about what it feels like to do TDD, in a kind of response to the articles and remarks by @jcoplien and @dhh and others. I agree, of course, that 100% line coverage, which you get for free with TDD, doesn't mean much in a theoretical sense.

1/6

Even 100% branch coverage doesn't mean much. While I don't subscribe to all the math in Cope's article, it's true that, theoretically, a program with high coverage can include plenty of errors.

What's interesting is that in practice, theory doesn't quite work.

2/6

If you TDD some little thing, making sure that every line of code you write is required by a meaningful test, and get it working, try this experiment.

Look at the code. Try to find places where a change to one or more lines will break the program but not break the tests.

3/6

Read 6 tweets

Share this page!

Ron Jeffries

Try unrolling a thread yourself!

More from @RonJeffries

Ron Jeffries

Ron Jeffries

Ron Jeffries

Ron Jeffries

Ron Jeffries

Ron Jeffries

Did Thread Reader help you today?

Like this author's thread?