¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: Examples of TDD/Junit antipatterns

[email protected]
 

Hi Pooja

Check out the Meszaros book "xUnit Test Patterns" and the concept of "Obscure Test".


The Nat Pryce / Steve Freeman book is also v good, especially around acceptance test first development.


I think?the main misunderstandings / pitfalls of TDD today are layed out here...?

also???


Lastly, most engineers seem to be classicists... is that because we were taught how to test systems?


?

Lastly, Mark Seeman has some good courses on TDD - highly recommended
Re: [TDD] Examples of TDD/Junit antipatterns

 

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

 

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 that can explain the TDD/Junit antipatetrms better. This is one of the precautionary thing we want to follow. Any resources / pointers will be of great help.?



Thanks,

Pooja
Re: [TDD] Suggestion, advice on TDD adoption

 

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

-Pooja
Re: [TDD] Suggestion, advice on TDD adoption

 

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 do is to provide resources, information and opportunities. Let them know what a true team is like. Give them the chance to be together. Help solve problems. The group may decide to become a team - in fact it's very likely if the conditions are right.

People are designed to work on teams. One just has to let them discover that fact.

Charlie

On Thu, Apr 7, 2016 at 9:00 AM, hotfusionman@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

Yes, the Socratic approach to learning can be great. At my office, I'm currently leading live TDD work sessions I've titled "Stump the Chump", emulating a technique my grad school mentor's mentor (my grand-mentor? :) ) used in teaching mathematical physics: show up to class and just try to work a problem, showing how it goes in real life rather than a prepared/rigged demo, complete with throw-it-all-away mistakes and all other sorts of warts. The idea is both to show that it works and to show how to succeed despite problems. In the process, even though I've done TDD for years, I too am learning things about both TDD and how to teach it.

me

On Apr 7, 2016, 08:49 -0700, Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...>, wrote:

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 helps build "buy in" to the cultural changes needed.

On Apr 7, 2016 6:42 PM, "Steven Gordon sgordonphd@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:
?

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 attend when they can.? There could be local experts who would be able to do some dojos or presentations for much less expense than a full-time coach.
Re: [TDD] Suggestion, advice on TDD adoption

 

Re: [TDD] Suggestion, advice on TDD adoption

 

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 helps build "buy in" to the cultural changes needed.

On Apr 7, 2016 6:42 PM, "Steven Gordon sgordonphd@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?

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 attend when they can.? There could be local experts who would be able to do some dojos or presentations for much less expense than a full-time coach.
Re: [TDD] Suggestion, advice on TDD adoption

 

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 attend when they can.? There could be local experts who would be able to do some dojos or presentations for much less expense than a full-time coach.
Re: [TDD] Suggestion, advice on TDD adoption

[email protected]
 


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 trying to achieve, just in rough terms? ?Is it a big change? ?How much support in your team??

I will write something up, but fun hands on stuff works best, anything that will help devs and QAs to pair, dojos at lunchtime with some good sandwiches : )

Cheers

Ken
Re: [TDD] Suggestion, advice on TDD adoption

 



On Wed, Apr 6, 2016 at 6:01 PM, Russell Gold russ@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?


On Apr 6, 2016, at 4:57 PM, Keith Ray keith.ray@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

It really really helps to have a coach working with your team and its code.


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 lot of time. You can get some of it from books such as Robert Martin¡¯s??(and other books in the series), but a good coach is still much better.



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 is very similar to hiring a senior developer¡ªthe one you want you cannot afford and the one you can afford you don¡¯t want.?

You CAN do it without a coach. You can potentially avoid a number of pitfalls and delays with a good coach. It is a business decision whether the price of the coach is worth the reduction in risk.?
Re: [TDD] Suggestion, advice on TDD adoption

 

¿ªÔÆÌåÓý


On Apr 6, 2016, at 4:57 PM, Keith Ray keith.ray@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

It really really helps to have a coach working with your team and its code.


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 lot of time. You can get some of it from books such as Robert Martin¡¯s??(and other books in the series), but a good coach is still much better.


On Apr 6, 2016, at 4:53 AM,?poojawandile@...?[testdrivendevelopment] <testdrivendevelopment@...> wrote:

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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?
-----------------
Author,?Getting Started with Apache Maven <>
Author, HttpUnit <> and SimpleStub <>

Come read my webnovel,?Take a Lemon?<>,?
and listen to the Misfile radio play <>!
Re: [TDD] Suggestion, advice on TDD adoption

Keith Ray
 

¿ªÔÆÌåÓý

It really really helps to have a coach working with your team and its code.

C. Keith Ray
twitter: @ckeithray


On Apr 6, 2016, at 4:53 AM, poojawandile@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?


Thanks,

pooja
Re: [TDD] Suggestion, advice on TDD adoption

 



On Wed, Apr 6, 2016 at 1:40 PM, Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

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 through the process of learning what good (non fragile, non brittle) tests look like and how to write them.


Keeping the tests informative (i.e. fail only for the right reason and do so quickly) requires deliberate effort either way. It is mostly impossible to write tests that aren¡¯t brittle around code that is. That is why I suggest strongly that you keep refactoring until you have a ¡°good OO design.¡± Defining that is a little bit complicated and probably belongs in its own thread.?

If you write brittle tests around brittle code and then say, ¡°Okay, it¡¯s covered. Now we¡¯re done,¡± then you either know less about design than you need to or you are in denial (It could definitely also be both.)?

The advantage of working with legacy code however is that you have better defined acceptance tests etc.


It depends how legacy your legacy code is. I have encountered systems where the requirements were defined in a document no one had read and what the code did was not what the document said. I have encountered other systems where the only requirement was that the system keep doing whatever it was that it did, and no current employee knew what that was.?
Re: [TDD] Suggestion, advice on TDD adoption

 

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 through the process of learning what good (non fragile, non brittle) tests look like and how to write them.

The advantage of working with legacy code however is that you have better defined acceptance tests etc.

On Apr 6, 2016 11:29 PM, "Adam Sroka adam.sroka@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?



On Wed, Apr 6, 2016 at 4:53 AM, poojawandile@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?



Al makes a good point, although I wouldn¡¯t say, ¡°orders of magnitude more difficult.¡±?

You are going to spend a lot of time writing tests for code that already exists and then having to break that code in order to make it testable. This is not exactly TDD. In fact, it is the problem that TDD was designed to solve.?

It is good advice to spend a little time test-driving new code to get your feet wet, especially for programmers who are less experienced overall.?

Additionally,

1. Focus on getting something wrapped in a test and then refactoring under test until you have a good solid OO design within the boundary of the test. It will feel like you are refactoring way too much at first, but pushing all the way to the boundary is the only chance you have to make the design better rather than just not worse.?

2. Get in the habit of treating every test failure in integration as an emergency. Don¡¯t succumb to the temptation to treat intermittent failures as normal. It will undermine the culture of quality and rapid feedback that you are trying to build.?

3. It is really hard to overstate the value of pair programming and continuous integration in this context. These practices are very synergistic, and you will get better results faster if you do them together.?
Re: [TDD] Suggestion, advice on TDD adoption

 



On Wed, Apr 6, 2016 at 4:53 AM, poojawandile@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?



Al makes a good point, although I wouldn¡¯t say, ¡°orders of magnitude more difficult.¡±?

You are going to spend a lot of time writing tests for code that already exists and then having to break that code in order to make it testable. This is not exactly TDD. In fact, it is the problem that TDD was designed to solve.?

It is good advice to spend a little time test-driving new code to get your feet wet, especially for programmers who are less experienced overall.?

Additionally,

1. Focus on getting something wrapped in a test and then refactoring under test until you have a good solid OO design within the boundary of the test. It will feel like you are refactoring way too much at first, but pushing all the way to the boundary is the only chance you have to make the design better rather than just not worse.?

2. Get in the habit of treating every test failure in integration as an emergency. Don¡¯t succumb to the temptation to treat intermittent failures as normal. It will undermine the culture of quality and rapid feedback that you are trying to build.?

3. It is really hard to overstate the value of pair programming and continuous integration in this context. These practices are very synergistic, and you will get better results faster if you do them together.?
Re: [TDD] Suggestion, advice on TDD adoption

 

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 you to start TDD with net-new code. ?It could be new methods within existing classes, if you don't have any truly greenfield areas of code to work on.

Al


On Wednesday, April 6, 2016 4:53 AM, "poojawandile@... [testdrivendevelopment]" wrote:




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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?

Thanks,
pooja
Suggestion, advice on TDD adoption

 

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 journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people.?


Thanks,

pooja
Re: [TDD] Giving Up on TDD

 

That is what Dave said in the video :)

On Mar 31, 2016 5:18 PM, "Mark Levison mark@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?



On Thu, Mar 31, 2016 at 9:47 AM, Alan Baljeu alanbaljeu@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

A more credentialed rejection of TDD, coming from Dave Thomas, one of the original writers of the Agile Manifesto (which for reasons he explains here, he would rather call a manifesto on agility).? The linked time discusses about the value of testing practices .

?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 opinion of whether or not TDD (or any other practice) is good influence our willingness to try and experiment. Person X says something. So what? Run an experiment prove them right or wrong.

Confused in Ottawa
Mark?


--

Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
Certified Product Owner & Private Training?also available ~?
?|?
Proud Sponsor of??and?
Re: [TDD] Giving Up on TDD

 



On Thu, Mar 31, 2016 at 9:47 AM, Alan Baljeu alanbaljeu@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?

A more credentialed rejection of TDD, coming from Dave Thomas, one of the original writers of the Agile Manifesto (which for reasons he explains here, he would rather call a manifesto on agility).? The linked time discusses about the value of testing practices .

?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 opinion of whether or not TDD (or any other practice) is good influence our willingness to try and experiment. Person X says something. So what? Run an experiment prove them right or wrong.

Confused in Ottawa
Mark?


--

Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
Certified Product Owner & Private Training?also available ~?
?|?
Proud Sponsor of??and?
Re: [TDD] Giving Up on TDD

 

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.

On Mar 31, 2016 4:48 PM, "Alan Baljeu alanbaljeu@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?

A more credentialed rejection of TDD, coming from Dave Thomas, one of the original writers of the Agile Manifesto (which for reasons he explains here, he would rather call a manifesto on agility).? The linked time discusses about the value of testing practices .

?
?
?
?
?
?
?
Preview by Yahoo
?

?
Alan Baljeu


From: "Avi Kessner akessner@... [testdrivendevelopment]" <testdrivendevelopment@...>
To: testdrivendevelopment@...
Sent: Thursday, March 31, 2016 8:46 AM
Subject: Re: [TDD] Giving Up on TDD

?
I have to shake my head that the need for TDD still isn't better understood.
I guess the current generation has been living their whole life where "Nothing ever works", that they see no need to ensure that it does, actually indeed work.

I'm glad to see that at least there is agreement that tests are needed at some point, but they still don't seem to get that TDD is the only way to have confirmation as to what areas of your code needs testing.

brought to you by the letters A, V, and I
and the number 47

On Thu, Mar 31, 2016 at 1:52 PM, Josue Barbosa dos Santos josuesantos@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?
For Knowledge
621 - 640 of 36280