Very Good , thank you!

I look forward to this wonderful series. Thanks for doing this!

Looking forward to seeing the whole series!

Nice. Thank you for taking time to create this. This video lessons should be viewed also by .NET people. I liked the fact that you have explained even the most obvious things, this is very important. For example, in the first video you explained the bad smell code called “Feature Envy” and the solution to it. Great!!!!

Simply amazing thanks Brett!

Awesome video. Very informative.

Looking forward to the rest!

Great videos! I especially liked your explanation of BDD style and the Testcase Class per Fixture pattern.

I saw you run into problems with running all the tests together. My way of doing it is running the whole package first just as you did, but later on I use a shortcut bound to command “Rerun JUnit Test”. You can define shortcut for this action in eclipse preferences.

Also note that if you press alt+shift+x, j (or mac equivalent) when the cursor is on a test method, then only this test is run.

alt+shift+x, t I meant of course

in chinese, I don’t access the http://vimeo.com, would you mind give some other alternative web address or direct download address.

thanks!

Excellent stuff. A very nice refresher on the basics of TDD. Looking forward to next episodes.

The first video is excellent.

I look forward to see the rest of the series.

It would be interesting if you could provide some info on how to handle the incorporation of the infrastructure/architectural “stuff” while practicing TDD/BDD. Things like db, logging, exception handling and so on.

Big thanks.

zhaorui,

Try the following link: http://schuchert.wikispaces.com/VideoDemonstrations.

That probably won’t work. If not, is there a site I can upload the videos to that you will be able to access? They are too big to email.

I browsed through the “Getting started” video and it looked promising (I’ll have a better look after sleeping).

It appears that your style of organizing tests is quite close to my style, when you split the test class for RpnCalculator into ANewlyCreatedRpnCalculatorShould and ACalculatorWithThreeValuesShould. (Although I have dropped the “should” word long time ago, because it was not adding value but only noise. IMO, the value is in focusing on the behaviour/features, not in using some predefined words. But unfortunately many testing frameworks force the use of some predefined words, for example “should” or “it”, in the test names, so that it inclines the users to organize their tests always the same way, which sometimes is suboptimal.)

A problem with JUnit is that it does not natively support that style of organizing tests, so by default I use some different testing framework. But since JUnit is popular and widely supported, it’s a good choice when teaching TDD. Fortunately it was quite easy to make a custom JUnit runner which allows nesting those test fixtures into one top-level test class (someday I’ll release that class as its own Maven artifact). Then it’s possible to put all the related tests into the same file using that style, so that it’s easier to get an idea that what some component/feature does, because everything that relates to that component/feature is in one place (here are some simple and more complex examples).

I really liked your videos. I am sure that it took a lot of time to complete them so huge congrats to you.

I just have few small comments :

1. In ANewlyCreatedRpnCalculatorShould test class you do not need to declare @Before method. It would be enought to have just:

private RpnCalculator calculator = new RpnCalculator();

And this field will be initialize before every test method (just like @Before method).

The same applies for OperandStackTest.

2. I do not see any reasons to have both setAcumulator() and enter() methods. On mac calculator that you have shown “enter” is needed because one has to confirm that he/she finished typing the number. There is no need to do this in your program since you do not have any method that collects digits to create a number, so imho enter() is redundant.

3. You should use code template named “test”. If you would write it in eclipse editor and then hit alt+space() twice then enter you would get template:

@Before public void testname(){ }

it will save you a lot of typing.

4. to run all tests in single package just select it in “package explorer” and then just alt+shift+x,t(). To run all test in a single project again select it in package explorer view and hit the same short cut. It is a lot faster then context menu.

5. I like that you do not put parenthesis in one line blocks of for/if/... we have the same convention in our company.

6. why you are not splitting test method body into //given //when //then section? We are practicing this convention in our company and I have to admit that it gives additional readability.

7. ctrl+/ for commenting selected lines ;)

I hope to see more your videos.

Cheers!

(*) – ale my shortcuts are for non-mac keyboard of course ;)

“eclipse editor and then hit alt+space() twice then enter you would get template: “

of course ctrl +space not alt+space

@Esko If think that Categories in JUnit is something, you can use to group few Test Classes into one. Maybe its API is not so great :) but Kent Beck posted1 that he wants to change it in future JUnit releases.

[1] http://www.threeriversinstitute.org/blog/?p=456

I should use more shortcuts. Problem is, I keep switching languages and development environments and OS’s, so it’s tough to get they into muscle memory. That’s a good thing for a kata!

As for using a template, I won’t do that unless I show setting it up. In fact, if you notice in those videos, I end up with an extra “}” quite often. I use a vi plugin for eclipse and it works much better to turn off that feature. But I’m doing close to native eclipse, so there won’t be any surprises. However, I think it would be useful (based on this feedback) to:

• Set up a template
• Configure Eclipse
• Mention that I’ve done this early on (and maybe remind people of that fact)
• Have a video with that configuration and setup.

Regarding not using @Before versus using it. Old habits die hard. In any case, I’m not convinced of that behavior across xunit testing tools, I use multiple tools, so I try to keep habits that will work in all situations.

I will say, however, I’ve been VERY tempted to do that. In fact, I did that in one of the videos (I think), then I “fixed” it. That’s a style issue for me.

Esko wrote:

I have dropped the “should” word long time ago, because it was not adding value but only noise

... You forgot to add “in your opinion” to that. You’ve stated this “fact” as truth, but in fact that’s your opinion. We’ve already had several arguments you and I.

Micha wrote:

6. why you are not splitting test method body into //given //when //then section?

I don’t do that for several reasons:

• Never picked up the habit.
• Think it can make the test longer and not add a lot of value
• Prefer the “given” as the fixture
• Prefer one or afew number of “then”, which is the last line

However, I do like that style for acceptance tests and integration tests. I just don’t like the ceremony for unit level tests. AND this is all my opinion. If that form of organization works for you/your group/your company, you should continue do it.

... You forgot to add “in your opinion” to that. You’ve stated this “fact” as truth, but in fact that’s your opinion.

You didn’t directly say it, but is it your opinion that the “should” word brings value? Could you expand on that? What in your opinion is the difference between “new calculator has 0 in its accumulator” and “new calculator should have 0 in its accumulator”?

FYI The last two videos 7 (mockito) +8 (factory) do not have commentary…silence! Someone mentioned that the downloaded movie had sound, but I would rather not have to register for vimeo.

Really enjoying this series you’re putting together. I appreciate this as I am trying to become a TDD developer, but do not have anyone to work with/learn from. thanls

enjoyed the introduction video very much and like the idea of using BDD naming in the unit tests (the idea of context driven test fixtures). This approach was new to me and I like it.

one suggestion, if you don’t mind, your not covering both the inner and outer loop of TDD. It would be good to see an example of an outer acceptance test driving the inner unit testing.

looking forward to the rest of the series and just want to say thanks for putting these videos together and making them available.

Brett, Thanks for fixing the audio on the last couple of videos. Really enjoying the series, and I am following along with my own project in C#. cheers!

iPad Mate, enjoy the hd video freely on iPAD

i believe you are good at writing. a good writter need many good topics

M2TS to MKV Converter is the best software for user to convert M2TS to MKV file, With the powerful M2TS to MKV converter,you can convert M2TS to MKV with best quality and convert M2TS to all the video formats.m2ts to mkv converter

Good idea to make a series of videos on TDD. AVI to iPad

Nice work! Keep up your good job.

Sorching summer, is coming. The most comfortable, put a cool and refreshing way, wear a dress out of fashion, wear a comfortable , should be the one summer MMS chasing dreams. Bright colours by all the summer dress up, also can let your mood will no longer dry frowsty upset!

Flower skirt seems to be in summer, forever ChanYi as thin as the flower skirt, can not only a cool summer, and all sorts of design and color, let you do in summer “ever-changing princess”, plus all sorts of collocation, individual character is dye-in-the-wood, the flower skirt collocation of snow, cowboy ma3 jia3, formed the integral style of contrast, let you both cooling and handsome!Tie-in skill: flower skirt handsome ma3 jia3

thanks for sharing