开云体育

Very well said Russ! ________________________________ To: testdrivendevelopment@... Sent: Sunday, June 2, 2013 5:12 AM Subject: Re: [TDD] Erroneous Assertion about TDD "is there any

"is there any room left for creativity in coding?" That's hilarious. Let's reach back in time� As poets focus more on rhyme schemes and meter, where is there room for creativity? Now they have this

--- John Carter <john.carter@...> wrote: There is no "right." We strive to do a good job. But there is always room for improvement. You try your best ideas with the team. And then you, as a team,

John Carter wrote: I think you have a lot of good stuff in there and it would be worth making a presentation as someone else on the list suggested. Also for anyone learning TDD and testing I

Jonh, In the GOOS list someone asked it: worth it? The context was that, for him, may be only ATs (Acceptance Tests) was enough. Follows my answer why I still value unit tests. As you write about

John C, Is there some way you can add a bit of structure? Personally I find it hard to read because it's just a bunch of sentences with no paragraphing and no headings. Perhaps if you can think of it

Two thoughts: 1) if you aren't finding smells in your own code that means you've stopped learning. Have someone else look and listen to what they say. 2) there are always too many places to look.

The following is aimed at a my own team, but before I inflict it on them, I thought I would run past the wise folks of this forum. Suggestions, comments, flames all welcome. What I write below is

Hi All, I'm announcing the release of NUnitLite 0.9 today. In case you were not aware, NUnitLite has surprised me by attracting a lot of users who previously used full-on NUnit. I originally

I came up with an easy way to generate Mikado diagrams programmatically using Ruby-Graphviz. 聽One of the co-authors of the book (Ola) liked it. 聽Here's an example. 聽The Mikado has two direct

I for one think it's a very good book on its own merit. There are other good books on TDD, and GOOS is certainly one of the best, but I think it's better to read and ponder this one

Test Driven Development by Example (Kent Beck) + 4 GOOS + 2 Refactoring + 2 Working Effectively With Legacy Code + 2 Clean Code + 1 The Mikado Method (mikadomethod.org) RSpec Agile Software

Now THAT is a Very Good Find! An Excellent Book! Thanks, just what I was hoping for! -- ------------------------------ This email, including any attachments, is only for the intended recipient.

It could, but it doesn't necessarily. The only time I have ever seen it become a problem is when someone was doing something they shouldn't irrespective of the fact that it was in a test. Also, it's

Adam, Thanks for the admonition. I was just trying to explain how monkey-patching causes more interference between tests than mocks do. - George

Perl was my first professional language. I am not afraid of monkey patching. A hammer is a useful tool. Please refrain from hitting yourself with it.

Adam, No, with monkey patching you're often messing up *library code* to the detriment of other tests. Maybe. Or maybe your monkey patching makes other tests work, but the app doesn't when it's in

Hi George: That makes sense, but you can do the same thing to yourself with mocks. That's why you have to make sure you write microtests for both sides of the relationship and cover the same

Adam, Monkey patching is a common method to create testing seams, even by people who would not use monkey patching in the deliverable system code. It's a quick-and-dirty way of mocking using the real

Well - the same thing kind-of applies in perl. Default initialisation and left over correct values can lead to the wrong behaviour in Perl too. I'm sure there are per-language issues - but those