We all did it a couple of times, but it wasn't until recently that I found out how useful and efficient it was. Our fresh hires start working on production code relatively soon after their first day. Nevertheless we want to review their work before check-in.
Getting up to speed
I always start with, "Let me see the tests". It is only partially to emphasise the importance of tests, the real reason is that for me it's easier and quicker to engage in the task he has just solved. And this gives me the chance to profoundly review the code itself and how it looks.
Defining
Sometimes we don't even continue to the code, because it turns out that he misinterpreted the task at hand, and solved something else. But that's okay too, for through the tests I can very easily and clearly explain what the real task is. If we were to do this via the implementation, it would be less unambiguous.
Demonstrating
Finally, I can show him couple of coding tricks, again without being too superficial, yet being quite quick. What I mean is I can quickly refactor his code on the spot, without saying things like "... and you can imagine the rest" - no, at the end of the demonstration we have a still working code(checked by the help of the tests), but with me already having made my points on coding as we know it: expressive and duplication free.
Read full post...
Showing posts with label tdd. Show all posts
Showing posts with label tdd. Show all posts
Thursday, 20 October 2011
Wednesday, 3 March 2010
Assert First Development
A good programmer writes about 10 lines of code a day. Maybe less maybe more, though it's a very interresting topic leading to names like Barry Boehm and Tom DeMarco, it's not the subject of this post. I just wanted to point out that eventhough undoubtedly useful, IntelliSense, or any autocompletion tool for that matter, is way overrated. A programmer might type in that single line of code of the hour in five minutes, or in eight without IntelliSense. I'm glad we've got that out of the way. Next, if you are a TDDer and don't already use the Arrange/Act/Assert concept, start today and you will never look back. Anyways.
"Assert First Development"[1] is about writing the assert of your test first. This gives you the means to write the act-part in a way your assert needs it, and then the arrange-part as your act and assert needs it. This way you have to think about only one thing at a time. If you do it the other way around - that is from arrange to assert - you always have to think about all three parts simultaneously. You could of course say "I'm very smart and I can think about many things at once", and I believe you can, but you could use all your cleverness to solve one problem at a time, potentially solving things even better. If not, you still haven't lost anything, you just did your job sequentially. But chances are that your assert will be right the first time around, not mentioning your arrange in which you set really only those things up your act needs, and not the things you think your act will need. Only thing you lose is some parts of your IntelliSense, but we already established that it's really not that much of a loss.
One last thought. Assert First Development is another great example of the pull-system: there is never waste produced, we don't setup mocks or fakes or anything we might not need eventually.
References:
[1] Kent Beck: Test Driven Development: By Example
Read full post...
"Assert First Development"[1] is about writing the assert of your test first. This gives you the means to write the act-part in a way your assert needs it, and then the arrange-part as your act and assert needs it. This way you have to think about only one thing at a time. If you do it the other way around - that is from arrange to assert - you always have to think about all three parts simultaneously. You could of course say "I'm very smart and I can think about many things at once", and I believe you can, but you could use all your cleverness to solve one problem at a time, potentially solving things even better. If not, you still haven't lost anything, you just did your job sequentially. But chances are that your assert will be right the first time around, not mentioning your arrange in which you set really only those things up your act needs, and not the things you think your act will need. Only thing you lose is some parts of your IntelliSense, but we already established that it's really not that much of a loss.
One last thought. Assert First Development is another great example of the pull-system: there is never waste produced, we don't setup mocks or fakes or anything we might not need eventually.
References:
[1] Kent Beck: Test Driven Development: By Example
Read full post...
Tuesday, 29 December 2009
Transformers
Much of the agile literaure is focused on how difficult the transition from traditional to agile could be. They address the problem from many angles describing techniques how to help programmers to make peace with pair programming, how to get better at incremental design, some even suggest to use Organizational Patterns to introduce some of the practices to a team or a company. They all seem to be empathic with people who as a rule fear and loath change.
I don't see it that way. I actually think being a true "waterfall guy" helps you to accept agile, and helps you to execute XP practices and to a better outcome too(from this point on I'll be referring to XP, but probably most of what I have to say applies to other agile methodologies as well)
Having had been a true waterfall guy myself, with my precious UML diagrams, my very own modules and an ever strengthening habit of working alone on a laptop in pubs and cafes only occasionally checking in my work for my team to see, I had no problem at all transitioning to XP -- quite the contrary.
I enjoyed Pair Programming from Day 1, because I realised how much easier it is to pick one from the many possible ways to solve a problem, if you have someone competent to discuss it with. I learned not to fear to be stuck anymore, simply because it happens almost never, and even if it does, it's far less frustrating when you have someone next to you to share the pain. Becuse of all the implicit and explicit problems I had with the tradtional way, I appreciated Pair Programming a lot more then I would have otherwise.
To be able to do Incremental Design it's good to have had done a few BDUF yourself. It helps you to see the big picture - which some false interpretation of incremental desgin denies to be allowed - and it helps you to come up with sophisticated solutions quickly. But most importantly once you have seen first hand what's wrong with BDUF, you are ready to like Incremental Design for all of its benefits.
TDD is again something you appriciate more coming from a Waterfall world, because then you know how fustrating the bugfixing phase normally is, fixing and refixing bugs for months. You also know how frustraing and shameful it is not to make changes to code you hate and not to refactor at all due to either fear of breaking something, or an explicit order from your bosses, with something about changes are risky at this stage of the project, but the right stage for a change never seems to come. In which BTW they are absolutely right: without an extensive test harness, you can never be sure, even a little, that the changes you're about to make won't break the whole system.
All in all, the skills you learned and the bad experiences you had with waterfall all will make you a better agile developer.
Read full post...
I don't see it that way. I actually think being a true "waterfall guy" helps you to accept agile, and helps you to execute XP practices and to a better outcome too(from this point on I'll be referring to XP, but probably most of what I have to say applies to other agile methodologies as well)
Having had been a true waterfall guy myself, with my precious UML diagrams, my very own modules and an ever strengthening habit of working alone on a laptop in pubs and cafes only occasionally checking in my work for my team to see, I had no problem at all transitioning to XP -- quite the contrary.
I enjoyed Pair Programming from Day 1, because I realised how much easier it is to pick one from the many possible ways to solve a problem, if you have someone competent to discuss it with. I learned not to fear to be stuck anymore, simply because it happens almost never, and even if it does, it's far less frustrating when you have someone next to you to share the pain. Becuse of all the implicit and explicit problems I had with the tradtional way, I appreciated Pair Programming a lot more then I would have otherwise.
To be able to do Incremental Design it's good to have had done a few BDUF yourself. It helps you to see the big picture - which some false interpretation of incremental desgin denies to be allowed - and it helps you to come up with sophisticated solutions quickly. But most importantly once you have seen first hand what's wrong with BDUF, you are ready to like Incremental Design for all of its benefits.
TDD is again something you appriciate more coming from a Waterfall world, because then you know how fustrating the bugfixing phase normally is, fixing and refixing bugs for months. You also know how frustraing and shameful it is not to make changes to code you hate and not to refactor at all due to either fear of breaking something, or an explicit order from your bosses, with something about changes are risky at this stage of the project, but the right stage for a change never seems to come. In which BTW they are absolutely right: without an extensive test harness, you can never be sure, even a little, that the changes you're about to make won't break the whole system.
All in all, the skills you learned and the bad experiences you had with waterfall all will make you a better agile developer.
Read full post...
Friday, 23 October 2009
Case closed
Many heated arguments about Test-Driven Development have certain recurring reasoning on both sides. In general, developers have a hard time accepting that they need to think differently about implementation and design and/or have to alter exisitng design in order to be able to write tests. "I would need to introduce this indirection only for testing" or "There is no need for this kind of hierarchy to implement the features in the production system", and their alikes are common critiques of TDD.
Inexperienced TDD people almost invariably try to tackle these with answers like "But your design will be better this way" or "Modularity is your friend" or "Indirection is a way to build flexibilty into your code".
Obviously all of these are correct and nothing new. SOLID for example is a well-known and universal set of principles supporting the answers above. However most of the defenders of TDD are missing the point.
The point is this:
Once we've agreed that unit testing is a very efficient way to create quality software and we want to do it, there is no room for further discussion. You just have to think about the testability of your code as any other requirement you have to implement. Don't worry, you will get all the earlier mentioned: flexibility, maintainability, comprehensibility, and so on. But that shouldn't have influence on this praticular matter, because you are required to write testable code anyway. There is really nothing else to it.
Once you can get your head around this, your life as an agile programmer will be much, much easier. Mine already is.
Read full post...
Inexperienced TDD people almost invariably try to tackle these with answers like "But your design will be better this way" or "Modularity is your friend" or "Indirection is a way to build flexibilty into your code".
Obviously all of these are correct and nothing new. SOLID for example is a well-known and universal set of principles supporting the answers above. However most of the defenders of TDD are missing the point.
The point is this:
Once we've agreed that unit testing is a very efficient way to create quality software and we want to do it, there is no room for further discussion. You just have to think about the testability of your code as any other requirement you have to implement. Don't worry, you will get all the earlier mentioned: flexibility, maintainability, comprehensibility, and so on. But that shouldn't have influence on this praticular matter, because you are required to write testable code anyway. There is really nothing else to it.
Once you can get your head around this, your life as an agile programmer will be much, much easier. Mine already is.
Read full post...
Subscribe to:
Posts (Atom)