While you are coding.

Chapter 6. Common knowledge with programming is once the codding part beggins is all about the keyboard the machine and the programmer, in reality programming is another kind of communication, and communications requieres understanding, being careful with what you do, and knowing what you do, what it does and why it does that, otherway we may end up coding by concidence.

rglfizfThat sweet sweet corsair K70 will have to wait until after proper colaboration with the testing team is stablished.

The programmers need to know the algorithm speed of the methods they created, most nontrivial  algorithms handle some kind of variable input. Normally the size of this input will affect the algorithm: the larger the input, the longer the running time or the more memory used.

More significant algorithms are not linear. The good news is that many are sublinear. A binary search, for example, doesn’t need to look at every candidate when finding a match. The bad news is that other algorithms are considerably worse than linear; runtimes or memory requirements increase fer faster than n. An algorithm that takes a minute to precess ten items may take a lifetime to process 100.

xw539eaRobbie Rotten finds out the intern name selection bubble sort.

Moving forth and afar from the diferent kinds of algoriths that may take another post or two to talk about. The next thing we need to take into account when coding is the refactoring. Refactoring the action of reviewing the code and modifing the code in order to make it more organic and natural the the solution in question. Clearly refactoring is an activity that needs to be undertaken slowly, deliberately and carefully.

Testing against contract

We like to think of unit testing as testing against contract. We want to write test cases that ensure that a given unit honors its contract. This will tell us two things: whether the code meet the contract, and whether the contract means what we think it means. We want to test that the module delivers the functionality it promises, over a wide range of test cases and boundary conditions.

What does this mean in practice? Let’s look at the square root routine.

require:
    argument >=0;
ensure:
    ((result * result) - argument).abs <= epsilon * argument;

this tells us what to test:

  • Pass in a negative argument and ensure that is rejected.
  • Pass in an argument of zero to ensure that it is accepted.
  • Pass in values between zero and the maximum expressible argument and verify that the defference between the square of the result and the original argument is less than some small fraction of the argument.

This style of testing requires you to test subcomponents of a module first. Once the subcomponents have been verified, then the module itself can be tested.

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15
(2000).

Author: enroblog

Computer science student at ITESM

One thought on “While you are coding.”

  1. If unit testing is done at the time the module is fresh out the oven you would just be adding a minimal amount of work to ensure that it works. It’s similar to a layered structure, it may seem tiresome, but once a layer works you can assume it will work properly on higher layers.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: