drieuxster (drieuxster) wrote,
drieuxster
drieuxster

Why Test Based Software Development Is EVIL!!!!

Short Answer: Liberalism

It may help most folks get a sense of the approach as a starting point. I am also willing to concede that some facets of some development cycles are going to have problems with a test based development process. But those edge cases are, like all edge cases, mostly pointy, and will poke someones eye out if you go running around waving them about like that.

I will be using illustrations from perl, because, it is GOD's ONE TRUE AND ONLY CODING LANGUAGE, and all others are pale apostate spawns of the evil liberal media.
When In Wonder,
When In Doubt!
Invoke the YSIR { You Suck, I Rule } Protocol!!!
But to be reasonable, most folks outside of the perl community will be less emotionally traumatized by the threat of a not_as_serious a scripting language like perl, since of course, it is no longer one of the cool kids on the block, and is used only by old guys who have to actually deliver working code.

Basically the idea here is 'sort out what is testable, sort out what must be done first, organize the first test first'.

One of the most comical moments was watching an Enron Corporation Foolishly Hire Russians - and the poor chap went almost insane noticing that all of these alledged 'engineering specs' were full of Non-Testable assertions that so many people were snivellating about how to implement.

So if you is facing 'non-testable assertions' - consider that they may still be useful as MULCH, and put them in the compost pit to see if they can be more useful there.

Which can SOOO simplify life.... If in fact that Organic Fertilizer is useful somewhere else, it will be soooo much happier, and so will the software developers. The big challenge of course is explaining to the PHB's that , if it looks like The Church Turing Hypothesis, and it squacks like the Church Turing Hypothesis, that, well, there is just no Halting That Problem. Which may mean that it is time to help one's PHB learn about technical stuff and a safe way to differenciate between technical stuff and management stuff.

That being said, one of the most obvious upsides of the process is that one has almost a self defining solution space. One has tossed out, a priori, all of the non-testable assertions, including every coder's personal angst
But will my code respect me in the morning?
Deal with it scrub worm, there are many propositions that one just has to feed to the God's, and get past those brief Wittgensteinian moments.

Ok, so it is phase two that can be a bit complicated, since sorting out which propositions that are testable are to be ordered in which manner. This is unfortunately a very undeterministic problem, and as such will involve the fine art of Politics, with the evil:
Politics is the process by which groups of people make decisions. The term is generally applied to behavior within civil governments, but politics has been observed in all human group interactions, including corporate, academic, and religious institutions.[citation needed]
OH NO!!!

Yes, I am going to openly suggest that, as we all know, politics is merely WarStuff by other means, and as such, one really should NOT rule out the fine art of SHELLING THEM until they are willing to capitulate to your ordering of which testable propositions should be tested first. But let us not get side tracked into how one can always 'bomb to win' as a central part of the modern Corporate War Winning Strategies.

What is really fun here is that one starts with the first testable issue. When that is solved one moves forward. This strategy can help REMOVE 'analysis paralysis' - since the first things first approach helps re-inforce that this is NOT the time to be worrying about Solar Death and the end of life in the universe. For most of us, that is a testable problem a bit further down the stack, and will be addressed in it's time slot on the list.

Given our first proposition, one attempts to work out the key features of what needs to be tested. Then how to go about testing it.

When it comes to large software project that have many objects, and potentially long inheritance chains, one of the first tests that must be run is my favorite:
sub test_MethodName : Test {
my $self = shift;
Test::More::can_ok($self, 'MethodName');
return TRUE
}
since if MethodName is already taken, it may be worth while to see IF it does what one wants it to do.

This is also a great time to work out, whether to OverRide the method name, or look for a more descriptive name, or What?

Never Rule Out 'or What?' as it is a way to ponder, what ifs.... but remember that one is trying to build a test, and then that one is trying to get the verifications, etc, that one code will still respect you in the morning, even if you take ONLY your cellphone to the movie, and do not take your laptop with all of your source code.... { yes, some of us are still concerned that 'palmPilot' actually violates the computer decency act, but that too is another issue... }

So now that the test for MethodName fails, because NOW one has a MethodName that is not yet implemented. Now it is time to get more daring, by putting the MethodName into the source code, and show that the original failure goes away. NOTICE if you will that I am not so blithely optomistic as to say that 'it passes the test'. Merely that the failure notices have not come back. I would LOVE to believe that my code passes the tests, but all I can really assert is
My Code Failed To Fail!!!
Which is why we started the process out with testing if the name 'MethodName' was in use.

Since if it was, we have some research that we FAILED TO DO, and now would be a great time to do that research and sort out the whole thing about using the existing MethodName, or ...

As one moves forward with building out the tests, iteratively, one also has the clear indeterminancy problem of,
When is it merely PARANOID DELUSIONAL ANGST?
Trust me, this IS the core art part. Since, let us be honest, there are times when NOT having that 'cute test for foo' that will bleat out a warning that some condition was not met, is well, WRONG!!!!

Throw the EXCEPTION!!!! BLOW UP LOUD AND RUDELY!!! Tell The STINKING PRIMATE what you really think of them, and their whole failed evolutionary tree of DOOM AND DESPAIR.

Or not, depending upon one's sense of asthetic.

Since, well, sometimes the 'happy accident' will show that there was some condition that one did not think about when in the full fresh blush of thinking happy thots about Failing To Fail, and here is the wonderful Joyous Opportunity to decide whether this is an exception one needs to handle, or should one expand the documentation to note that in conditions IkkyGross this method will throw the YourPrimateInfestationsAreToBePurged Exception; all hail our robot masters.

In this way one has the chance to improve both the internal and external documentation, but also a clearer and cleaner sense of what this method is actually doing, in the way that it actually DOES THAT!!!

And this from the very gitGo!!!

Thus by the time one has it doing precisely what one alledged that this method should be doing, one also has the first round of the regresion testings.

One of the really Fuggly Moments is adding in more tests and finding out that one side effects an earlier test for, well, completely unexpected reasons. They are of course 'unexpected', since the earlier test would have been well mannered enough to worry about this problem... if it were an actually expected problem. But since the earlier tests did not guard against this unexpected turn of events, one gets the chance to better understand, and hence to document and/or FIX, the problem/process/mechanism that causes this side effect.

As you can see, this process just builds on top of itself.

IF one started, majikally, as can from time to time happen, with a greenfield code space, then one has built one's code with the understanding that it should become a revenue stream of some form over the course of it's existence - even if that is the part where the maintenance of the code is NOT GOING TO COST BIG BANK to keep around.

If, on the other hand, one is starting with legacy code, namely code lacking an appropriate test case framework. Well, one is adding value by making sure that the new stuff will not break the old stuff, as best as one can do that. Which of course starts by writing the test code to validate that the 'old code' has 'good enough' test coverage, BEFORE one starts tweeking it.

Then as one works one's way through the code, one can do the fun parts, like, establishing Best Practices, either because they conform to the manual for the specific coding language, or because one is in the process of building up the documentation to WRITE the coding language specific publication. { brief reminder, never rule out sustained mortar fire as a perlude to going over the top and establishing a Dominating Position as to which Best Practice will be maintained, or the shellings will begin again. }

It should be obvious by this point that these sorts of Practices are just WRONG!!!

If americans were to adopt them here in the realm of software development, they might leak out and escape into the wild, where innocent people would become infected with the idea that there are propositions that are testable, and there are propositions which may find a use supporting vegetable matter growth.

Clearly if that were to occur, then many more americans would be able to tell factually verifiable from mere BULLSHIT! and we can not have that, now can we.
Subscribe

  • What if we had to be a nation of laws

    First off a h/t to a dear fiend, for Crackdown on herd-share farms over certification which is such a classical attack of the FeeMarketeers meets…

  • why do folks forget the clinton years?

    Essentially I agree with When The Magic Starts in that there is much that will need to be undone from the failure of the deregulation game that was…

  • Oil does not grow on trees.

    Let us start from the premise that fossil fuels are not like renewable products such as fruits, vegetables and other forms of…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments