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.
That 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.
Robbie 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).
Proyect estimates.
Enro Blog 