Re: [extremeprogramming] The principle behind How Test-Driven Development Works

Why not. All I’m saying is this approach needs a listener. A teammate may work just fine.

Regards,

Slava Imeshev


> On Dec 2, 2019, at 8:21 AM, Steve Ropa <[email protected]> wrote:
> 
> 
> I prefer to think of the team collectively being responsible for the team’s output.  The manager might better spend her time being responsible to the team for enabling that output.  So if presenting the outcome of the work is desirable, maybe we could just present to the rest of the team?  Which, in my humble opinion, would include the manager, but only as a co-equal member of the team.
>
> Regards,
>
> Steve
>
> Sent from Mail for Windows 10
>
> From: Slava Imeshev via Groups.Io
> Sent: Saturday, November 30, 2019 5:25 PM
> To: [email protected]
> Subject: Re: [extremeprogramming] The principle behind How Test-Driven Development Works
>
> Managers are responsible for team’s output, so they may naturally be interested in raising team’s ability to get stuff done. Not all managers are like that or it may be a team that doesn’t have a leader yet.  In that case anyone who knows the subject and is willing to spend 30 min per week with the engineer and have a discussion or provide input will work. This can be a team mate, a study group or even a spouse.
>
> I came up with this approach after continuously finding myself launching use of best practices like XP at teams while not having time to do full blown teaching or running a couching model.
>
> It’s important that it doesn’t matter what part of subject sticks. It’s not a multiple choice question exercise. The note taking and reporting ensures that something sticks always.
>
> Regards,
>
> Slava Imeshev
>
>
> > On Nov 30, 2019, at 3:25 PM, Dave Nicolette <[email protected]> wrote:
> >
> > All good, but...why present to the manager?
> >
> >> On 11/30/19, Slava Imeshev via Groups.Io <[email protected]> wrote:
> >> Hi Guilherme,
> >>
> >> Guided self study is study of the subject by an engineer where they read
> >> some comfortable number of pages per week, take notes and present to their
> >> manager.
> >>
> >> The goal is to cover gaps in their abilities as software engineers. There’s
> >> days my favorite subjects are unit testing, OOP/OOD and refactoring for
> >> engineers.
> >>
> >> It works because it switches engineers from sleeping through the book to
> >> looking for information actively.
> >>
> >> As for testing untestable, I just start a Zoom or a Skype meeting with a
> >> teammate, refactor the class so that the dependencies are expressed as
> >> interfaces (extract method, extract class, extract interface) and then write
> >> a unit test to cover new logic and changed methods using mocks. The teammate
> >> grabs the keyboard any time they want.
> >>
> >> Regards,
> >>
> >> Slava Imeshev
> >>
> >>
> >>> On Nov 29, 2019, at 7:20 PM, Guilherme Froes <[email protected]>
> >>> wrote:
> >>>
> >>> 
> >>> Hi Slava!
> >>>
> >>> These days I just automatically launch a guided self study of refactoring
> >>> for any member of the team who doesn’t have it. A fun and highly
> >>> educational pair programming exercise is ‘making untestable testable’ when
> >>> I take a class that a teammate declared untestable, refactor it and cover
> >>> with unit tests under an hour.
> >>>
> >>> This guided self study and pair programming exercise sound really
> >>> interesting. Do you have something about this that you could share or is
> >>> it something you create ad-hoc?
> >>>
> >>> Thanks!
> >>>
> >>> -Guilherme Froes
> >>>
> >>>> Em sex., 29 de nov. de 2019 às 01:13, Slava Imeshev via Groups.Io
> >>>> <[email protected]> escreveu:
> >>>> I totally agree. TDD is hard if not impossible without designing to best
> >>>> practices.
> >>>>
> >>>> One design principle that seem to work consistently is Inversion of
> >>>> Control (IoC) aka Dependency Injection aka Programming to interfaces
> >>>> because one of its natural side effects is enabling use of mocks in unit
> >>>> tests.
> >>>>
> >>>> The second important component is knowledge and use of refactoring when
> >>>> dealing with a legacy code base because it enables making code testable.
> >>>> These days I just automatically launch a guided self study of refactoring
> >>>> for any member of the team who doesn’t have it. A fun and highly
> >>>> educational pair programming exercise is ‘making untestable testable’
> >>>> when I take a class that a teammate declared untestable, refactor it and
> >>>> cover with unit tests under an hour. God bless Martin Fowler.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Slava Imeshev
> >>>>
> >>>>
> >>>>>> On Nov 29, 2019, at 2:05 AM, Charlie Poole <[email protected]>
> >>>>>> wrote:
> >>>>>>
> >>>>> Most folks I know who are experts at TDD consider that design is part
> >>>>> of it. Some have even said "It might be called Test Driven Design."
> >>>>> However, traditionally, it isn't called that. My personal view is that
> >>>>> "Development" includes Design, so calling it TestDrivenDevelopment is
> >>>>> most appropriate. Those who prefer "Design" appear to think that
> >>>>> Development simply means programming, which is not what the word means
> >>>>> for me. A further problem with "Test Driven Design" is that many folks
> >>>>> still think of design as something that happens before development,
> >>>>> rather than as part of it.
> >>>>>
> >>>>> I've seen that some people use ATDD for testing at the story level,
> >>>>> others call it TDD. I prefer separate names but they both have design
> >>>>> elements as part of the "development."
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160373): https://groups.io/g/extremeprogramming/message/160373
Mute This Topic: https://groups.io/mt/39414677/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-