0:00:00.662,0:00:02.839
Hey, everyone.

0:00:02.876,0:00:04.965
I am David Heinemeier Hansson.

0:00:04.997,0:00:07.672
I'm here with the Martin Fowler and Kent Beck

0:00:07.741,0:00:12.706
to talk about "is TDD dead?" as the topic.

0:00:12.751,0:00:19.763
Coming off keynote I did at Rails conference and subsequent articles I posted on the blog.

0:00:19.826,0:00:23.500
I had chance to talk with both Kent and Martin

0:00:23.500,0:00:26.911
one on one in the days that followed.

0:00:26.972,0:00:30.260
and we got to discussed a bunch of these issues

0:00:30.290,0:00:35.652
and I got to clarify some thoughts and definitions that I had in my head

0:00:35.731,0:00:40.034
and got a lot wiser about where both Martin and Kent are on the issue

0:00:40.093,0:00:44.411
and Kent suggested that, "Hey. Maybe we should share that with world."

0:00:44.469,0:00:46.771
So that's what we're doing now.

0:00:46.824,0:00:51.970
I know bunch of people have been expecting to this is gonna be a big???

0:00:52.007,0:00:53.651
there'll be no boxing.

0:00:53.721,0:00:59.061
We'll explore bunch of definitions and problems and patterns we've seen.

0:00:59.061,0:01:03.414
and what's work for us individually and go from there

0:01:03.459,0:01:06.630
But to get started, I thought

0:01:06.713,0:01:11.012
I just run over brief recap of the problems that I've seen with TDD

0:01:11.111,0:01:13.631
use that to kick off the discussion

0:01:13.681,0:01:19.360
and really three major points that all focus on this discussion.

0:01:19.360,0:01:24.070
The first is the definition of TDD and its components

0:01:24.126,0:01:26.443
specifically unit testing.

0:01:26.522,0:01:30.391
I know the TDD and unit testing are certainly not the same thing

0:01:30.453,0:01:34.440
but TDD's often used to drive unit test

0:01:34.470,0:01:37.180
and as I was looking through

0:01:37.234,0:01:41.332
issues I've been in the Rails world around TDD

0:01:41.384,0:01:44.270
a lot of that came down to the definition of unit testing.

0:01:44.328,0:01:46.920
that people were defining unit testing as

0:01:46.955,0:01:49.710
you can't have collaborators

0:01:49.769,0:01:51.334
you can't touch the databases

0:01:51.379,0:01:52.770
you can't touch the filesystem

0:01:52.770,0:02:01.420
goal was to have a suite of unit tests so fast that they could complete in a blink of an eye.

0:02:01.490,0:02:03.130
I've seen arguments of

0:02:03.166,0:02:07.630
if it takes more than 300 milliseconds to complete the entire suite then it's way too slow.

0:02:07.670,0:02:08.630
I can't use it for anything.

0:02:08.686,0:02:13.800
and that just wasn't matching my useful definition of unit testing

0:02:13.800,0:02:16.892
and it wasn't matching what I was trying to get out of it.

0:02:16.957,0:02:22.661
and frankly I wasn't get anything useful out of unit tests that weren't talking to any collaborators.

0:02:22.719,0:02:29.190
Second, which follows from that is driving your architecture through Mocks.

0:02:29.257,0:02:33.811
If you want everything in your test suite to be so super fast

0:02:33.902,0:02:36.622
well obviously you have to talk to mocks

0:02:36.680,0:02:38.182
you can't talk to anything slow

0:02:38.182,0:02:40.711
and you can't talk to many layers at once

0:02:40.790,0:02:47.270
which leads to a mock sort of heavy and enabling architecture

0:02:47.331,0:02:51.861
repositories and hexagonal pattrerns

0:02:51.861,0:02:56.870
and all these other things that makes very easy to stuff and mock your way out of everything

0:02:56.946,0:03:00.590
and turn every test you could imagine into unit tests

0:03:00.650,0:03:03.480
MVC framework as I work with rails

0:03:03.544,0:03:08.611
the controller, "Oh, no problem. Just stuff out everything talking to the view"

0:03:08.648,0:03:12.810
"talking to the model and then that's gonna be great."

0:03:12.858,0:03:15.940
I was not seeing that being very great at all

0:03:15.995,0:03:19.503
the key point what I thought

0:03:19.557,0:03:22.061
this is test induced damage

0:03:22.160,0:03:30.210
that the architect is actually suffering damage from this drive towards unit testing all the things

0:03:30.262,0:03:35.670
and that the unit testing all the things is coming through the TDD pipe.

0:03:35.754,0:03:41.150
And then finally this sort of ..... TDD

0:03:41.235,0:03:43.201
is the read green refactor loop.

0:03:43.266,0:03:47.090
And that was more of, sort of personal thing.

0:03:47.144,0:03:51.850
We can all have our own personal preferences and how we develop things

0:03:51.938,0:03:57.561
in TDD red-green refactor seemed .... more of mandate

0:03:57.648,0:04:03.632
I never dealt with that for the bulk of the work that I do

0:04:03.714,0:04:08.052
at certain locations at work and at certain locations that flow was good

0:04:08.106,0:04:12.732
but I felt like there there's tons of code that I was writing were red green refactor

0:04:12.790,0:04:14.611
just not an enjoyable of way to do it.

0:04:14.663,0:04:18.291
and I didn't feel like I was going to a better place by going through that

0:04:18.320,0:04:24.791
So those sort of the three top-line problems that I think with the TDD

0:04:24.856,0:04:27.481
Let's sort of the open conversation up

0:04:27.518,0:04:33.970
and have Martin and Kent chime in perhaps one at a time

0:04:33.970,0:04:36.130
What is unit test?

0:04:36.196,0:04:38.630
What's useful definition of unit test?

0:04:38.695,0:04:43.900
What's useful definition of unit test and how most people currently defining it in you guys' view.

0:04:43.963,0:04:46.632
Well, I propose

0:04:46.632,0:04:48.920
in order to understand something

0:04:48.980,0:04:51.510
I often find it useful to know how it came about.

0:04:51.599,0:04:57.896
And the style of unit testing we familiar with is basically all Kent's fault.

0:04:57.956,0:05:02.591
Right? Because Kent did the framework, XUnit frameworks

0:05:02.656,0:05:05.382
whole push through extreme programming

0:05:05.382,0:05:07.360
so maybe we start with that

0:05:07.360,0:05:11.110
where those source of this style of unit testing come from.

0:05:11.191,0:05:13.622
You're the guy. You explain it.

0:05:13.662,0:05:20.424
Can you hear me?

0:05:20.457,0:05:22.973
Yep.

0:05:23.040,0:05:31.350
So when I was a kid

0:05:31.453,0:05:33.255
I would read books about programming

0:05:33.320,0:05:35.061
I was just fascinated by programming.

0:05:35.131,0:05:38.105
I'm talking about nine, ten, eleven years old

0:05:38.144,0:05:39.877
and my dad was a programmer

0:05:39.877,0:05:42.076
so there're lots of books about programming around.

0:05:42.139,0:05:48.288
And he had a book and I would read I didn't understand anything

0:05:48.346,0:05:52.516
but I was just sorta compulsively reading these books

0:05:52.586,0:05:54.613
cause I found the whole topics fascinating

0:05:54.613,0:05:59.074
there was a book that said, "Here's how you program."

0:05:59.158,0:06:05.285
"You type in the output tape that you expect your program to produce given some input tape"

0:06:05.347,0:06:12.815
"And in programming is, you just write program and tell it produces the output tape that you expected."

0:06:12.869,0:06:18.934
So that was kind of fixed way back in my brain as the flow of programming.

0:06:19.006,0:06:24.786
And it wasn't until after I had been testing for a while

0:06:24.831,0:06:31.315
that already come up with the first version of SUnit, the Smalltalk testing framework

0:06:31.399,0:06:33.025
that was the precursor to JUnit.

0:06:33.065,0:06:40.664
and I remember this idea of writing the test before writing the code

0:06:40.664,0:06:41.825
which makes no sense, right?

0:06:41.825,0:06:44.794
the test is gonna fail and you want the test succeed.

0:06:44.794,0:06:48.905
so why would you write it when you knew it was gonna fail?

0:06:48.905,0:06:50.994
So I just tried it.

0:06:50.994,0:06:59.045
One of my heuristics is, "If an idea is obviously bad, find the cheap way to try it

0:06:59.045,0:07:02.854
because if it turns out it's not bad then it's really interesting

0:07:02.854,0:07:04.977
if you have a good idea and it's obviously good

0:07:05.044,0:07:08.384
somebody else's probably tried it before.

0:07:08.425,0:07:12.854
So, I just figured I'd try and I think I built stack at first time.

0:07:12.940,0:07:16.266
and it worked really really for me.

0:07:16.266,0:07:26.454
i think there's aspects of my personality that make this kind of peicemeal style work really well

0:07:26.614,0:07:33.329
I have a lot of anxiety and I tend to get overwhelmed by big problems

0:07:33.329,0:07:37.706
and for me TDD solves those problems.

0:07:37.706,0:07:43.919
Even if I don't know how to implement something I can almost always figure out how to wright tests for it

0:07:44.004,0:07:49.645
and if I can't figure out how to write a test for it, I have no business in programming in the first places.

0:07:49.758,0:07:54.251
So, that's how got into it.

0:07:54.251,0:07:57.539
And it was definitely ground up

0:07:57.588,0:08:04.977
that is, I started with small green problems and gradually work my way to larger green problem."

0:08:04.977,0:08:08.554
Go ahead.

0:08:08.586,0:08:13.517
I was thinking about this on reflecting back on our early days together

0:08:13.675,0:08:18.516
and if I recall correctly when we began working

0:08:18.516,0:08:22.339
??? using extreme programming ???

0:08:22.339,0:08:25.494
we did the testing very strongly from the beginning

0:08:25.552,0:08:27.226
but it wasn't test first at beginning.

0:08:27.298,0:08:30.866
I've got this memory of you standing up and saying

0:08:30.943,0:08:37.256
"The stories are not done until the codes're written and the tests're written and the tests are passing.

0:08:37.313,0:08:40.725
So we have the notion that you delivered at the end of it

0:08:40.822,0:08:43.272
increment of functionality with code and tests together

0:08:43.358,0:08:46.403
but test first didn't actually followed till later.

0:08:46.477,0:08:52.695
I can't remember when that came because it seemed gradually appeared.

0:08:52.788,0:08:57.819
but I feel that at that very beginning the focus was on the tests.

0:08:57.896,0:09:00.109
on the tests with that but that's the first as it were

0:09:00.206,0:09:06.302
so I think one of the fundamental question is

0:09:06.335,0:09:10.210
as a programmer do you deserve to feel confident?

0:09:10.254,0:09:17.830
I certainly grew up in culture that didn't encourage that.

0:09:17.878,0:09:21.153
You know, you write some stuff and just hope it works

0:09:21.187,0:09:23.486
somebody else would tell you whether they thought it worked.

0:09:23.565,0:09:29.209
and you go home on Friday and just think

0:09:29.241,0:09:31.065
"Oh god. I just hope I didn't break something."

0:09:31.107,0:09:37.670
and so I think the going a step back from TDD or automated testing

0:09:37.705,0:09:40.505
"do you deserve to feel the confidence?"

0:09:40.505,0:09:41.550
"can you sleep at night?"

0:09:41.606,0:09:44.497
knowing that your code works

0:09:44.550,0:09:46.882
I think the answer should be Yes for programmer.

0:09:46.978,0:09:50.822
So if we agree on that then we can talk about how to achieve that.

0:09:50.822,0:09:53.426
TDD is one way to achieve that.

0:09:53.426,0:09:55.075
There's lots of other ways.

0:09:55.136,0:09:58.744
I think that it's a great point because

0:09:58.744,0:10:01.540
one of the things that really got me into programming was

0:10:01.628,0:10:03.383
was Ruby.

0:10:03.476,0:10:05.995
Right. So I've been programming before Ruby but

0:10:06.030,0:10:12.070
this language that has a very specific mission statement.

0:10:12.070,0:10:14.025
Programmer Happiness

0:10:14.025,0:10:16.790
Right. So I think those two are related

0:10:16.871,0:10:23.095
the programmer happiness is certainly related to feeling confident in your code

0:10:23.095,0:10:24.895
and confident in making changes to it

0:10:24.895,0:10:26.531
and confident that's going to work

0:10:26.531,0:10:28.550
But it's only one part of that picture

0:10:28.660,0:10:32.460
and early days Martin described were

0:10:32.460,0:10:36.530
"Oh. You're not done until you also have tests for piece of functionality.

0:10:36.530,0:10:38.249
I'm completely on board with that. Right?

0:10:38.270,0:10:40.432
Where I'm not on board is that

0:10:40.675,0:10:45.483
that whole feeling of feeling great about your development style

0:10:45.483,0:10:48.830
feeling programmer happiness as Matz would always put it.

0:10:48.830,0:10:52.754
Just I wasn't getting that from TDD, right?

0:10:52.754,0:10:56.108
So maybe that's some of the patterns we talked about

0:10:56.138,0:10:59.793
different people with different brain style, right?

0:10:59.793,0:11:02.330
Why do some people enjoy Python?

0:11:02.330,0:11:03.830
Why do some people enjoy Ruby?

0:11:03.830,0:11:08.928
and even harder for me to comprehend how some people enjoy Java.

0:11:09.015,0:11:13.273
But but we sort of have different ways of looking at things

0:11:13.273,0:11:14.655
and feeling good about them.

0:11:14.655,0:11:19.126
and what I was finding just from the red green refactor flow

0:11:19.218,0:11:22.975
was that the whole notion of writing to test first and seeing that fail

0:11:22.975,0:11:25.751
and doing that for every piece of code before I move forward

0:11:25.751,0:11:28.892
was just not natural

0:11:28.892,0:11:31.904
because a natural you can overcome just by familiarity

0:11:31.904,0:11:37.599
but even through familiarity it was just not a pleasurable flow

0:11:37.599,0:11:43.745
and I think that's where a lot of the explosive debate comes from

0:11:43.745,0:11:51.528
to some people writing your thesis first and filling in the implementation with that works really well.

0:11:51.569,0:11:52.986
That's exactly how their brain operates

0:11:53.097,0:11:56.925
For other people, me included, it doesn't work like that.

0:11:56.963,0:12:01.817
It's much more tactile experience that I actually have to sit in and write it out

0:12:01.900,0:12:03.287
that's how I think through it

0:12:03.287,0:12:09.375
I don't think through it by proposing hypothesis up first and then try to fill it in.

0:12:09.375,0:12:11.513
I think through it by writing it out

0:12:11.513,0:12:17.807
If I can't write test first I have no business writing it.

0:12:17.838,0:12:22.705
That's I totally understand how that you can arrived at

0:12:22.780,0:12:24.888
It's just not at all how I feel about it.

0:12:24.888,0:12:29.684
I have a hard time writing a test forward, if I don't see it first, right?

0:12:29.684,0:12:33.131
SO you have sort of these some people like it from

0:12:33.191,0:12:35.664
going through the test

0:12:35.664,0:12:37.665
and other people like going to the test.

0:12:37.756,0:12:39.075
I think .

0:12:39.151,0:12:42.438
certainly important to realize we're both getting to same place

0:12:42.438,0:12:45.194
getting to fell confident about the code

0:12:45.267,0:12:47.451
confident making the changes to the code

0:12:47.534,0:12:52.610
that's the part I'm not a fan of tying these two things together

0:12:52.610,0:12:53.536
I'm not a fan of tying

0:12:53.536,0:12:56.876
oh you just have to be confident to TDD

0:12:56.945,0:12:59.389
which, I know you're not doing, right?

0:12:59.457,0:13:01.719
TDD is one path of getting to that place

0:13:01.776,0:13:05.172
I've seen there're a lot of people are mistaken those two things

0:13:05.232,0:13:07.336
that you can't have confidence

0:13:07.336,0:13:10.056
you can't deliver incremental functionality with test

0:13:10.156,0:13:15.632
unless you go through this mandated well paid road of TDD

0:13:15.632,0:13:21.974
so, last night was hackathon at Facebook

0:13:21.974,0:13:28.885
and I have a project on a internal tool that I was working on.

0:13:28.948,0:13:32.847
and half of it I could use TDD for

0:13:32.906,0:13:34.291
and half of it I couldn't

0:13:34.351,0:13:37.667
so I had a big log that I wanted to process

0:13:37.780,0:13:43.600
and the entries in the log were not clearly specified anywhere

0:13:43.697,0:13:46.715
but I wanted to put them into a data structure

0:13:46.715,0:13:51.627
kind of funky new data structure

0:13:51.627,0:13:56.355
the data structure I could build with TDD is just fine

0:13:56.355,0:13:59.282
because I could break it down

0:13:59.388,0:14:02.320
ok, here's the main case

0:14:02.320,0:14:03.351
here's the corner cases

0:14:03.414,0:14:05.701
here's how I go from one to many

0:14:05.771,0:14:08.293
just nice sequence of tests

0:14:08.375,0:14:13.312
and I can get into real flow

0:14:13.312,0:14:16.676
just make one test work and the next one and the next one

0:14:16.676,0:14:19.230
so that feels a certain way to me

0:14:19.313,0:14:22.980
when I had to fiddle live data into it

0:14:23.090,0:14:25.273
it feels very different way

0:14:25.273,0:14:28.254
because I don't have that clear specification

0:14:28.349,0:14:32.514
I just have to run a few million log entries through this first

0:14:32.514,0:14:34.138
and see what blows up

0:14:34.138,0:14:36.766
so I put in logging

0:14:36.830,0:14:39.712
I put in exception handling

0:14:39.774,0:14:44.676
so any log entry that's kind of funky that isn't handle by the code

0:14:44.676,0:14:47.374
get saved some place

0:14:47.374,0:14:53.530
then I can't go back and look at those entries that I can't handle yet

0:14:53.600,0:14:56.284
and I can use them

0:14:56.357,0:14:58.867
but I can't write a test for it

0:14:58.867,0:15:01.169
because I don't even know what the inputs look like

0:15:01.169,0:15:03.554
and that feels different way to me

0:15:03.554,0:15:08.800
so with the parts of the code that I can use TDD for

0:15:08.896,0:15:10.439
I mean a real flow

0:15:10.533,0:15:11.890
write a test, make it work

0:15:11.890,0:15:12.782
write a test, make it work

0:15:12.782,0:15:14.646
??? 12:30

0:15:14.646,0:15:17.319
I really like that feeling

0:15:17.404,0:15:23.375
the ones where I have to run on live ???

0:15:23.486,0:15:24.319
see what happens

0:15:24.319,0:15:26.820
I fee a lot more anxiety

0:15:26.916,0:15:31.244
but you know it's called work for reason

0:15:31.244,0:15:37.394
so I'm going to use the principles of double checking of regression testing

0:15:37.465,0:15:39.399
of short feedback loops

0:15:39.399,0:15:43.039
and try to get the shortest possible feedback loop

0:15:43.043,0:15:46.385
out of this unpredictable input that I'm getting

0:15:46.385,0:15:50.767
so I had to mix the two styles in one night

0:15:50.767,0:15:52.371
and it doesn't bother me

0:15:52.371,0:15:59.168
if I can play classical and jazz then I'm in a better position to make music for more people

0:15:59.230,0:16:05.035
but when I can reduce a problem to this sequence of tests

0:16:05.035,0:16:08.325
drive the solution from this sequence of test

0:16:08.385,0:16:10.550
it has special kind of feeling

0:16:10.616,0:16:12.208
for me it works really well

0:16:12.208,0:16:15.504
if I think back to how learned a ??? map

0:16:15.574,0:16:17.102
I always used these examples

0:16:17.181,0:16:19.901
you know there'd be some general

0:16:19.901,0:16:22.682
you know, prove this statement

0:16:22.778,0:16:26.532
and I think well, "what's an example of that"

0:16:26.615,0:16:28.682
and then I come up with a few examples

0:16:28.823,0:16:31.612
and I convince myself either the statement was true or that wasn't

0:16:31.675,0:16:33.209
and then I can write the proof

0:16:33.267,0:16:35.496
but that's my personal flow

0:16:35.586,0:16:38.641
I work from specific to general

0:16:38.641,0:16:40.356
this kind of inductive style

0:16:40.437,0:16:42.908
and I understand not everybody likes that

0:16:42.908,0:16:44.975
what I think is interesting though

0:16:45.056,0:16:47.531
even if I've been in that flow too

0:16:47.593,0:16:51.349
I had been in flow where TDD was working our well for me

0:16:51.441,0:16:53.711
it was ??? I should describe ???

0:16:53.771,0:16:55.253
it was very clear input

0:16:55.342,0:16:56.858
and was very clear desired output

0:16:56.858,0:16:59.761
and there were not a lot of contacts??

0:16:59.844,0:17:01.908
and there was not a lot of environment

0:17:01.969,0:17:03.620
to operate it

0:17:03.620,0:17:05.179
it was very pure

0:17:05.179,0:17:07.638
and for that

0:17:07.725,0:17:12.360
that would probably one case where I do actually like that flow

0:17:12.360,0:17:16.165
what I find is a lot of my work is not like that

0:17:16.226,0:17:21.067
right? sort of fundamentally maybe not like that

0:17:21.067,0:17:26.348
and then the problem comes in what am I willing to sacrifice to get that

0:17:26.348,0:17:29.342
you can reduce any type of work

0:17:29.411,0:17:31.908
certainly in the web space ???if you doing to that flow

0:17:32.012,0:17:35.320
if you just, that's where the whole mocking thing comes in, right?

0:17:35.387,0:17:38.827
if you just find a way and work hard enough

0:17:38.908,0:17:41.526
you can remove all the sort of dependencies

0:17:41.526,0:17:45.834
all the environment and reduce it to just one piece of input and one piece of output

0:17:45.834,0:17:53.211
is the flow important enough that you want to do that as general case?

0:17:53.282,0:17:58.214
how much you willing to sacrifice to be in that flow more ???you work

0:17:58.214,0:18:00.636
for me the answer has been

0:18:00.722,0:18:03.071
"I'm not willing to sacrifice that much."

0:18:03.133,0:18:04.721
when the flow is natural

0:18:04.721,0:18:07.586
when the work is sort of almost algorithmic nature

0:18:07.586,0:18:11.113
separated from all this context

0:18:11.180,0:18:13.587
alright. great. let's switch into that mode

0:18:13.587,0:18:19.394
but forcing all sort of other kinds of program work into this mode

0:18:19.455,0:18:22.548
just such that we can't feel the TDD loop?

0:18:22.618,0:18:26.276
that's where really see that we're going off track

0:18:26.342,0:18:28.433
and just coming up with some

0:18:28.493,0:18:33.409
in my opinion nasty hats we're starting really bad trade offs

0:18:33.499,0:18:38.385
for other aspects of the design of the code ????

0:18:38.385,0:18:41.261
so I'm curious for both of you guys

0:18:41.261,0:18:44.717
how much you guys willing to sacrifice to get to that TDD flow?

0:18:44.784,0:18:48.160
are you willing to use heavy amount of mocking

0:18:48.222,0:18:51.414
do you find that generally you can get there

0:18:51.536,0:18:54.798
in, say, MVC style programming?

0:18:54.858,0:18:57.417
or where the boundaries for you guys.

0:18:57.480,0:19:03.304
Martin is waiting for me talk

0:19:03.381,0:19:04.566
so I guess I'm talking.

0:19:04.566,0:19:07.278
so as I see I do this all the time

0:19:07.278,0:19:09.640
it's a question of trade off

0:19:09.722,0:19:13.141
and my students see me do that at thousands times

0:19:13.141,0:19:16.350
so for me TDD is question of trade offs

0:19:16.448,0:19:21.091
and I think, David you pointed out an important part of trade off which is

0:19:21.154,0:19:29.316
to make a design intermediate results testable comes with a cost

0:19:29.401,0:19:32.253
it comes with a benefit too

0:19:32.253,0:19:37.272
and you gotta figure out whether the costs outweigh the benefits

0:19:37.272,0:19:42.806
sometimes that's a question of understanding how to design things well

0:19:42.948,0:19:46.304
so if I'm building a compiler

0:19:46.395,0:19:50.553
and I think well the only kind of test I can have are end to end tests

0:19:50.615,0:19:56.199
and then I start to build more and more cases of what the input looks like

0:19:56.199,0:19:59.764
and I realize, "oh, I have this intermediate representation of parse tree"

0:19:59.851,0:20:02.988
then now I can test parsing

0:20:02.988,0:20:05.382
now I have this two orthogonal dimensions

0:20:05.382,0:20:08.530
I have parsing and then given a parse tree

0:20:08.594,0:20:10.362
does it compute the right results?

0:20:10.449,0:20:15.272
and then I can do more testing at a finer grain

0:20:15.272,0:20:19.408
but it was a design insight that created that moment

0:20:19.501,0:20:25.910
and compilers have settled on that as being a reasonable trade off

0:20:25.910,0:20:28.593
"ok, it's worth having this intermediate representation"

0:20:28.657,0:20:34.248
"so that we can have testability and bunch of other stuffs comes along with it."

0:20:34.317,0:20:37.570
so I'm not willing to say

0:20:37.570,0:20:44.906
ok, there's some fixed boundaries and I don't wanna twist design just to make things testable

0:20:44.906,0:20:49.191
because I'm just missing some design idea

0:20:49.191,0:20:51.098
if I had better idea for the design

0:20:51.102,0:20:53.284
then I could have both ways

0:20:53.284,0:20:59.658
I could have something that was more static more flexible design and it was more testable at the same time.

0:20:59.658,0:21:02.408
but if I don't have that today

0:21:02.408,0:21:05.298
your point is exactly right

0:21:05.298,0:21:06.459
then what do you do?

0:21:06.459,0:21:09.822
do you mock absolutely everything?

0:21:09.822,0:21:12.704
my personal practice is I mock almost nothing

0:21:12.704,0:21:17.189
if I can't figure out how test efficiently with the real stuff

0:21:17.253,0:21:21.598
I find another way of creating feed back look for myself

0:21:21.662,0:21:23.047
I have to have feed back loop

0:21:23.047,0:21:25.817
and a feed back loop has to be repeatable

0:21:25.888,0:21:34.580
but like I just don't go very far down the mock path

0:21:34.580,0:21:41.538
look at code where you have mocks returning mocks returning mocks

0:21:41.538,0:21:44.463
and my experience is

0:21:44.534,0:21:48.584
if i use TDD I can refactor stuff

0:21:48.584,0:21:50.224
and then I heard this stories

0:21:50.310,0:21:54.664
People say, "I use TDD and now I can't refactor anything"

0:21:54.664,0:21:56.202
I couldn't understand that

0:21:56.202,0:21:58.252
and then I started to looking at their tests

0:21:58.252,0:22:02.481
well. if you have mocks returning mocks returning mocks

0:22:02.546,0:22:07.580
your test is completely coupled to the implementation. not the interface

0:22:07.580,0:22:09.971
but the exact implementation of some object

0:22:10.039,0:22:11.888
you know three streets away

0:22:11.958,0:22:15.490
of course you can't change anything without breaking the tests

0:22:15.490,0:22:18.628
so that for me is too higher price to pay

0:22:18.699,0:22:20.930
that's not a trad off I'm willing to make

0:22:20.930,0:22:24.844
just to get piecemeal development

0:22:24.912,0:22:28.597
And this is, I think, at the heart of much of this

0:22:28.652,0:22:32.171
is confusion of terminology

0:22:32.243,0:22:34.637
and what these different things are

0:22:34.637,0:22:40.976
when I read David's initial blog post

0:22:40.976,0:22:44.192
cause I didn't see his talk until last night

0:22:44.192,0:22:47.015
one of things that came through very clearly

0:22:47.132,0:22:49.704
was his criticism of

0:22:49.775,0:22:53.149
David, your criticism of TDD

0:22:53.236,0:22:56.742
and sort of design damage that comes through it

0:22:56.835,0:23:01.595
had in itself very much tide in a notion

0:23:01.660,0:23:05.215
with the strong desire for isolation of mocking

0:23:05.302,0:23:11.516
and there, very important point that

0:23:11.660,0:23:13.220
there is nothing sort of

0:23:13.290,0:23:17.348
with in the idea of how you do either TDD or unit testing

0:23:17.388,0:23:20.116
that says you have to have that kind of isolation

0:23:20.124,0:23:22.696
some people are very much in favor of it

0:23:22.696,0:23:23.885
others are not

0:23:23.885,0:23:26.551
and I remember in the early days of extreme programming

0:23:26.622,0:23:28.432
unit testing, people would criticize us

0:23:28.434,0:23:32.044
that saying, "hey you're not isolating your units properly"

0:23:32.044,0:23:33.375
"that's not unit testing"

0:23:33.447,0:23:39.065
and we had this whole conversation with 24 different definitions of unit testing or whatever it was

0:23:39.065,0:23:41.412
ans said, "Well, our style of unit testing"

0:23:41.480,0:23:43.197
"we don't bubble about the isolation"

0:23:43.272,0:23:45.845
"and you know, it's working well for us, thank you very much"

0:23:45.913,0:23:48.934
so that's one thing

0:23:48.934,0:23:53.365
whether TDD in unit testing should be tide with isolation

0:23:53.436,0:23:55.635
and I look at it as different schools of thought

0:23:55.635,0:23:56.826
and I'm with Kent

0:23:56.919,0:23:57.806
I hardly ever use mocks

0:23:57.806,0:24:01.266
but I know good people who do

0:24:01.339,0:24:04.124
so I don't want to shoot everybody who uses mocks

0:24:04.124,0:24:05.770
maybe give it 10 more years

0:24:05.785,0:24:08.102
and then ????will ??? out or something

0:24:08.102,0:24:09.948
but we'll see

0:24:10.008,0:24:17.681
then there's another thing which is distinction between having what I call self testing code and TDD

0:24:17.749,0:24:23.249
to me, it's really important have self testing code

0:24:23.324,0:24:28.749
the ability to be able to run a single command have your whole system self test itself

0:24:28.749,0:24:30.098
in an acceptable amount of time

0:24:30.098,0:24:32.730
that is really powerful

0:24:32.888,0:24:37.010
because then if you can do that you can refactor with confidence

0:24:37.010,0:24:40.499
you've got a good chance of keeping your code base healthy

0:24:40.499,0:24:45.091
and that means you're able to be fast deliver new feature, etc

0:24:45.182,0:24:47.047
that is really powerful thing

0:24:47.116,0:24:50.521
and if I wanna get a ???high horse and say you must do something

0:24:50.652,0:24:54.360
I might be inclined to get that particular high horse.

0:24:54.360,0:24:56.410
but to me at least

0:24:56.410,0:24:59.326
TDD is one way to approach that

0:24:59.326,0:25:01.808
TDD is very particular technique

0:25:01.882,0:25:05.805
and if done well, one of benefit is that it gives you self testing code

0:25:05.931,0:25:07.329
give you all those benefits as well

0:25:07.408,0:25:11.447
but self testing code is for me perhaps the primary benefit

0:25:11.447,0:25:14.225
and the two get comflated

0:25:14.238,0:25:19.586
now fundamentally if somebody get self testing code by another root

0:25:19.658,0:25:20.813
such as when we started

0:25:20.884,0:25:25.761
we're delivering the code and the test together at the end of iteration

0:25:25.829,0:25:28.698
and you've got that self testing confidence

0:25:28.789,0:25:30.592
then I'm actually pretty happy

0:25:30.718,0:25:34.808
I'm not gonna kind of feel upset that somebody got that by another root

0:25:34.808,0:25:38.011
and I share with David and Kent

0:25:38.011,0:25:40.767
there're problems where TDD doesn't work terribly well

0:25:40.767,0:25:43.543
sadly most of programming I do these days

0:25:43.639,0:25:45.174
is not conducive to TDD

0:25:45.247,0:25:46.286
and I miss it

0:25:46.359,0:25:48.604
because actually I really like the TDD flow

0:25:48.604,0:25:49.988
that really works for me

0:25:49.988,0:25:51.369
just as it works for Kent

0:25:51.438,0:25:56.545
but fundamentally we have to separate TDD from self testing code

0:25:56.545,0:25:58.444
on realize they have different benefit

0:25:58.543,0:26:00.009
so often get conflated together

0:26:00.009,0:26:04.462
and we have to separate the idea of fully isolated unit testing

0:26:04.560,0:26:06.779
from not isolated unit testing

0:26:06.846,0:26:10.203
and realize that people have different preferences around those

0:26:10.312,0:26:13.252
and that's where I see

0:26:13.321,0:26:17.778
that was what much of my reaction was against, right?

0:26:17.874,0:26:21.712
that we had his prevailing definition of TDD

0:26:21.712,0:26:25.282
as not from you guys, from Kent

0:26:25.282,0:26:30.250
but from the people currently speaking in the program environment that I found was

0:26:30.347,0:26:31.903
A) very mock heavy

0:26:31.996,0:26:39.493
B) was very moralistic about the specific technique to get to the place we all want to get to

0:26:39.567,0:26:42.585
we all want to get to feel confident about making changes to the code

0:26:42.643,0:26:46.267
having self-test system that can run as a command and all these things

0:26:46.338,0:26:50.225
but you couldn't be part of that vote???

0:26:50.225,0:26:53.347
unless you also signed up for the TDD road to get there

0:26:53.456,0:26:57.884
and that's where I found it really frustrating

0:26:57.969,0:27:02.448
that we could have talked about whether we were being professionls or not

0:27:02.565,0:27:03.990
and that went through

0:27:03.990,0:27:05.572
well, you're writing test first

0:27:05.582,0:27:06.910
or you're writing them second

0:27:06.910,0:27:11.457
and related to that the whole TDD notion was propped up as

0:27:11.457,0:27:13.694
oh, well that self testing code you get

0:27:13.694,0:27:15.331
that's just a bi-product

0:27:15.406,0:27:23.333
that's a side benefit that some leftovers from driving your design through the tests, right?

0:27:23.406,0:27:28.092
that a lot of people really ??? onto this idea that TDD was not about self testing code

0:27:28.162,0:27:31.428
that was just a nice to have

0:27:31.428,0:27:33.501
but the key benefit was

0:27:33.568,0:27:38.040
the notion that you could only improve your design by making more testable

0:27:38.040,0:27:39.471
those two things equated

0:27:39.471,0:27:44.492
that easier to unit system was better designed system

0:27:44.492,0:27:50.149
that's the main heart of the fallacy and I want to take a real big swing at

0:27:50.241,0:27:53.706
because I started seeing a whole lot of code with this was not true at all

0:27:53.807,0:27:55.229
the code was not better

0:27:55.347,0:27:56.504
was not better design

0:27:56.577,0:27:58.371
just because it was more testable

0:27:58.371,0:27:59.764
it was full of these

0:27:59.852,0:28:02.208
mock that you guys talk about????

0:28:02.208,0:28:09.269
because we're trying to apply the unit test paradigm to areas of code that really didn't fit it very well

0:28:09.366,0:28:15.121
and we were discarding all sorts of really useful techniques, really useful patterns like Active Record

0:28:15.121,0:28:16.336
because it didn't fit

0:28:16.429,0:28:20.596
this notion of unit tests that had to run in 300 milliseconds

0:28:20.596,0:28:21.873
couldn't talk to the database

0:28:21.873,0:28:23.563
??? wasn't isolated, right?

0:28:23.563,0:28:27.339
so we had to throw out all these productive work

0:28:27.339,0:28:32.718
just so that we put ??? about alter of Test Driven Design

0:28:32.718,0:28:37.166
and that every aspect or our system could be unit tested in isolation

0:28:37.259,0:28:41.298
that's where I think we needed reboot

0:28:41.371,0:28:43.752
and I think we still need to reboot

0:28:43.833,0:28:44.929
we haven't rebooted enough

0:28:44.929,0:28:46.599
like these thing to still intermingled

0:28:46.599,0:28:51.759
and while I think we're all very much in the same page

0:28:51.830,0:28:53.943
and trying to tease these things apart

0:28:53.943,0:28:57.189
most people throwing all into one big pot

0:28:57.263,0:28:58.993
they're calling that pot, TDD

0:28:58.993,0:29:01.254
and TDD means self tested code

0:29:01.254,0:29:02.805
and it means red green refactor

0:29:02.805,0:29:06.035
and it means mocks because you have to unit test everything

0:29:06.035,0:29:10.225
and it means this big ball of shit in some ways

0:29:10.225,0:29:12.415
because that's what comes out of it

0:29:12.492,0:29:14.449
the dish in the end it's just not tasty

0:29:14.518,0:29:16.091
the code is not great

0:29:16.091,0:29:21.896
there're other more important sacred principles than it's just testable

0:29:21.896,0:29:24.479
as in if the system clear and understandable

0:29:24.479,0:29:26.463
and all the other aspects of it

0:29:26.463,0:29:29.180
so that's where my frustration really is

0:29:29.272,0:29:31.508
so I get to play time cut now

0:29:31.630,0:29:32.983
we said we'd do 30 minutes

0:29:32.983,0:29:34.759
30 minutes has come up

0:29:34.759,0:29:38.410
and it seems that we'll do another one of this hang out

0:29:38.483,0:29:41.390
sometime in the future we haven't decided yet

0:29:41.390,0:29:45.266
but I think one way we can immediately begin is to explore this question

0:29:45.266,0:29:50.312
in what ways can a desire to TDD damage an architecture

0:29:50.409,0:29:52.759
and is it damage, right?

0:29:52.759,0:29:58.390
some people say the hexagonal rails stuff is much better that crap DHH is imposing on us

0:29:58.465,0:29:59.862
is that the case?

0:29:59.934,0:30:01.006
how do we evaluate it?

0:30:01.100,0:30:04.356
those sound like good questions to tacklle in the text episode

0:30:04.444,0:30:07.940
alright, thanks a lot

0:30:11.116,0:30:15.964
we'll set up a new date and shoot out another link

0:30:16.039,0:30:17.484
that's great

0:30:17.559,0:30:20.430
bye, bye