开云体育

Hi Pooja Check out the Meszaros book "xUnit Test Patterns" and the concept of "Obscure Test". Obscure Test at XUnitPatterns.com http://xunitpatterns.com/Obscure%20Test.html Obscure Test at

It's been 10+ years of TDD, so people have had similar questions in the past. Search and you shall find :) http://stackoverflow.com/questions/333682

A BIG thanks to all who responded to my earlier post. During our discussion, we had this topic on TDD/Junit antipatterns. We did a bit of study and research on our own and are looking for examples

Thanks Ken. It will really help if you could share some of your learnings. -Pooja

There are many good ideas here. Try some of them. But keep this in the back of your mind: Management cannot create a team. A coach cannot create a team. Only the team can create itself. What you can

If you have the time, and can't find local coaches, assigning one member of your team to teach a session, and then rotating , could also help. I find teaching is often a great way to learn, and also

pooja, Not sure where you are located, but it might be worth looking into what local resources are available. Is there a Scrum or Agile Meetup (or Users Group)? If so, encourage your coworkers to

Yes, +1 to Adam I did some coaching work last year, lots of scrum teams, we had great fun, happy to share a few learnings from that, there were a few things that really worked. What are you

[testdrivendevelopment] <testdrivendevelopment@...> wrote: While I don’t disagree with this, the kind of coaching being described is expensive and people who can do it well are rare. It

This is really a key. Without a coach, you are going to wind up trying things, not understanding why they don’t work, and largely reinventing a lot of practices. A coach can save you an incredible

It really really helps to have a coach working with your team and its code. C. Keith Ray http://agilesolutionspace.blogspot.com/ twitter: @ckeithray

[testdrivendevelopment] <testdrivendevelopment@...> wrote: Keeping the tests informative (i.e. fail only for the right reason and do so quickly) requires deliberate effort either way. It

I think the hardest part of starting with legacy code is that as novices you will write brittle tests, and that is likely to give you bad design as you redactor. It's really important that you go

[testdrivendevelopment] <testdrivendevelopment@...> wrote: Al makes a good point, although I wouldn’t say, “orders of magnitude more difficult.” You are going to spend a lot of

TDD with existing non-TDD'ed code often is actually WELC (Working Effectively with Legacy Code, see the book of that title by Michael Feathers), which is orders of magnitude more difficult. ?I advise

HI, We have recently started using TDD. We have gone through the training, learned some of the TDD good practices/challenges, using junit, mockito tools/framework etc. Since its an early start to the

That is what Dave said in the video :) [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

[testdrivendevelopment] <testdrivendevelopment@...> wrote: ?I understand that you're not judging this or the other post, so my next comment isn't about you. Why would we let anyone's

Sounded like he said he does TDD in his head, since he has enough experience to know when and how to do that. Didn't sound like a rejection of TDD to me. [testdrivendevelopment]"