Never turn off resharper .. The best way to see how powerful it is, is to show it in action in real code

Pingback from  Dew Drop - December 30, 2008 | Alvin Ashcraft's Morning Dew

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #254

Well done.  There are some great thoughts in this post.  Cheers.

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to

say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Sarah

www.thetreadmillguide.com

Great post.  I spend about 1/2 of my time as a trainer, the other half doing code.  

I've taught mocking.  Lots.  I find if I start by showing how IOC and DI are useful, even outside the world of testing, students "get it" better.

Sort of like:

ME: Ok, one of the things this Customer class needs is the ability to send an email to the customer.  Should the customer class know how to send email?

Class (hopefully): No! Separation of Concerns!

ME: So, let's create a class the Customer uses to send email. .... anybody know how to send an email?

Class: silence.

ME: Ok, let's pretend like we do.  We'll create an interface that looks like it knows how to send email.  For now, we'll create a class that pretends to send an email, and tomorrow we'll figure out how to do it for real...

A little contrived - but it works.  We use constructor injection for our "fake" email sender, etc.  

When we move into Mocking and TDD they already understand the "hard" part. ;)

Great tips from you here.  Thanks.

Excellent suggestions.

Wow, I wish our Lead at Kaplan would have taken your attitude!  Nice post.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

However, reading this again.

I don't know what you mean when you said you turned off R#, for them or you?  Why?  If you're used to it, what benefit are you going to have by turning it off from someone who has continually told me to USE IT.

Great post! You really made some good points in there, and as I work as a consultant I often have to address the problem of implementing TDD in an organization. I often don't find it very hard to convince devs to start writing tests, because the list of advantages of using testing often speaks for itself. What I find hard is, as you point out, to teach them how to write good unit tests and to stay on the righteous path. It is quite a barrier to actually get going and I find that the learning curve often is a bit steep – especially for novice coders. Throwing testing frameworks, TDD test-first mentality, and mocking framework at someone who's not yet comfortable with neither C#, .Net or programming in general, could be just too much to handle. I haven’t thought of R# actually making the understanding even harder, but that is a very valid point and I will keep that in mind next time.

But I have found one method that I think works pretty well when it comes to teaching unit testing. I've blogged about it <href ="www.kjetilk.com/.../a>, but the essence is to sit down and do some pair-programming. And when doing the pair programming I start out writing the unit test first. This way I show them a bit how the testing framework work, how I structure the tests and often some use of mocking. Unit tests should be simple, so all in all the test should be fairly easy to understand even for junior devs. The worst part to explain is often the mocking, but using easy-to-read mocking frameworks like Moq helps a lot. Then when the test is written (and nothing compiles or passes) I hand over the keyboard to my fellow coder so that (s)he can implement the functionality. I simply tell her/him; "Make it go green!” Then we move on to the next test; I write the test, the 'soon-to-be-test-infected-dev' next to me writes the functionality.

Now, it's important to understand that at this point the dev(s) you are teaching are probably not yet convinced that this is the right way to code. The point where most devs seem to see the (green) light is when a test fails due to some code changes that they never thought would break any functionality. When the test that covers that functionality blows up, that's when you've got yourself a loyal TDD'er on your team. Or that's at least my experience, but as always; your mileage will vary :)

I had a suspicion that the link wouldn't render correctly... The blog post I meant to refer to was this: www.kjetilk.com/.../effectively-teaching-test-first-make-it.html