Tuesday, 21 October 2008

Unit tests are not enough (Part 2)

In a previous post I've explained why integration tests alone will not be enough to create a high quality product. However assuming that unit tests on their own will be enough is also a Mistake I don’t intend to repeat. There is great value in adding integration tests (and specifically doing writing them before coding is started) that is not gained by writing unit test. Desired Behavior Unit tests are testing the actual behavior of a single small component. A good set of unit tests will assure that a unit does exactly what its programmer has intended it do to. However when a programmer does not fully understood the DESIRED behavior, his misunderstanding will not be caught by any unit test HE writes. Writing some integration tests will not only make sure that all units behaved as desired,...

Sunday, 19 October 2008

Integration Tests are not enough (Part I)

In the last year or so I have learnt the hard way that Integration tests to are not enough.Throughout this post I'm using the term "integration tests" to refer to a more specific kind of tests which are also known as User Acceptance Tests (UAT)There is value in writing Unit tests (and specifically doing TDD) that is not gained by writing integration test.Design Integration test are design agnostic. The main goal of integration tests is the prove that the system is working correctly, from the USER point of view. At most, when these tests are done TDD style they will help the API's of the system to look better. If we want to leverage tests to drive the system technical design, the tests must be aware of the different parts which construct the system design (Units) and explicitly test each of...

Monday, 13 October 2008

Numbers Talk - Real Agile Case Studies

I've recently found about the existence of the Agile Bibliography Wiki.I believe this site is a must for all those interested in understanding the real measured effect various agile practices can have on projects.I admit though that after diving into it for a couple of hours there's too much for me to digest at once. Therefore I will need some time to see what hidden gems I can find there. The most interesting thing in this WIKI (for me) is the existence of case studies which examine the effect specific agile practices such as TDD, Pair programming have. This gives me a good starting point in trying to show organizations that even early stages in adapting agile methodologies can have a good ROI.At any case I would like to thank George Dinwiddie for pointing me to this si...

Sunday, 12 October 2008

Self Distracting Code

Here’s a code segment for you:#define OPDEF( id, s, pop, push, args, type, l, OpCode1, OpCode2, ctrl ) id,typedef enum enumOpcode{ #include "opcode.def" CEE_COUNT,/* number of instructions and macros pre-defined */} OPCODE;#undef OPDEFyes I’m back to old C++ hard core coding just in case someone is missing.Before I start let me assure you that this piece of code actually works and after understanding what it does, I admit it’s doing so quite cleverly.BUT:It took 3 experienced programmers, sharing about 15 years of C++ coding between them, 15 minutes to fully understand what is going on here.This segment is using one of the nastier tricks in the book – putting an “#include” statement in the middle of the file to achieve code replacement.At first look this code seems be doing nothing – we...

AUT in C++

Its been some time since I left the C++ field in favor of .NET development and recently I have taken some time to do some catching up. After focusing so intensely on developing a mocking framework it was only natural for me to start by looking what has changed in the areas AUT/TDD in C++.The bad news is that as far as I can tell, C++ AUT/TDD tools are still far behind in comparison to those found in .NET and Java. However there are some new tools on the block that seem to be heading the right direction so hopefully there is some change brewing.disclaimer: I am only starting to evaluate the changes and there is a good chance that I am missing some key change here.Therefore, for the sake of my own personal knowledge, I thought it will be nice to go over the tools I have found, and see if I...

Monday, 6 October 2008

Using Ready made solutions

Here's a paradox for you:Before starting to work as with .NET technology, I was a hard core C++ programmer. During that time the general approach around me was discouraging the use of external source components. The general attitude was always "we can do it better".This ingrained reflex was and still is one of the hardest thing for me to overcome. When starting to work with .NET, the developers around almost always tried to first find ready made solutions before reverting to coding themselves. Here's a nice post summarizing this approach: Search, Ask and only then Code.I find both approach somewhat funny:C++ - if we are such great programmers, humility would suggest that other programmers can do just as well, so their code would be just as good as ours. why not use it?.NET - if we can't write...

Sunday, 5 October 2008

Merge in SVN

At the end of the day there will be times in which branching will occur, resulting in the need to merge changes from one code line to another. Merging in an SVN system is a little different then what I expected resulting in me making Mistakes from time to time.Merge in SVN is a ternary operationI for one was used to treat merge as a binary operation. you take one source file and merge it into another resulting in the combined changes from them both. In SVN however, the merge operation always involves three factors. In fact I would think that a better name for merging in SVN would be “diff and apply”. When merging, we first take a given revision on a code line which we want to merge from compare it to some previous version on that line and apply the differences into a different code line that...

Friday, 3 October 2008

Source Branches

I hate branches. I think that branches are a bad solution for a stinking situation.now before you I get jumped, I’m aware that there are cases in which branches are a perfectly legitimate solution to a given situation, but still my advice would be to try looking at what is causing the need for the branch, in my experience there is an underlying problem that the branch will not solve.In the Last Alt .NET gathering I had a very nice discussion with Ken Egozi regarding branches. In that discussion ken and I represented the two opposites approaches. Ken on one hand is using Git and relies heavily on its great branching ability. To the point (if I understood him correctly) that he treat each source change as a different branch. I on the other hand uses SVN and try to avoid branches as much as I...

Thursday, 2 October 2008

Decoupling Testing from Design

A recent discussion has recently sparked up about whether or not can testing practices can be decoupled from design practices. Roy in his latest post "Unit Testing decoupled from Design == Adoption", has argued that one of the factor which prevents the masses from adopt AUT is the strong perception that AUT and design are strongly coupled, a perception which in his opinion is wrong. Udi on the other hand argues in "Unit Testing for Developers and Managers" that testing practices and design goes hand in hand.So can Testing be decoupled from Design?Well my answer is: Yes but probably not.The ContextTo clarify this cryptic answer I first need to put those practices in a context. As I see it, both design and testing are just means to reach an end. The ultimate goal is producing class A quality...

Pages 381234 »
 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons