Bad experience: Reasons why the last project was a disaster.

Usually I try my best to work in an ordered manner.
This means:

1. Interview the project manager (the person responsible for the success of the project) for the story.
2. Convert this story to requirements.
3. Present the project manager with the requirements.
4. If approved go to the next level.
5. Do a High Level Design (HLD) 
6. Present this HLD sidelong the requirements and estimate roughly the solution time in human days labor.
7. If approved go to the next level.
8. Breakdown the HLD to low level design (LLD).
9. Estimate LLD and present estimated more accurately time  in human labor.
10. If approved go to the next level.
11. Implement the LLD and stick to it (no time for adventures).
12. Do unit test, system test as much as i can (depends, sometimes not possible).
13. Present a working machine.
14. Be happy and relax.

This time, everything went wrong! Why?

Here were the flow of things:

1. Pressure to implement as fast as possible (reasons: no time, no budget).
1. I broke and agreed to 'be fast'.
2. Skip HLD + LLD, start implement! ==> no thoughts of risks, everything looks easy when you don't think about it deeply.
3. Implementation got some problems I didn't see in advance (and frankly, none can think that deeply).
4. More and more problems arose ==> delivery time breaks ==> more pressure.
5. No one is happy, all is waiting for the delivery => more pressure ==> shorter code, less secure code, BAD CODE!
6. ... The test-bench is too complex to operate... Catastrophic :-)

Next time - Do it right! 

If the project manager don't want to do it right, ignore him :), take your time, design it, show him the design, say 'i thought about it and found some problems' (when doing the hiding HLD + LLD).

You only get an advantage in the start, when things get rough (and they do!) you will cross the break-point and start to be slow (because you can't load all the HLD into your head).

In the end the project worked, the code, barely, but did managed to work, the time for this project took much longer then 'fast and short' (twice if not more the time it should take), and a bad taste was in the mouths.

GUIDE: LUA unit testing and TDD

I've just uncovered this subject, here is my insights:

Fast start

1. Open LUA
2. Start a new test file (let's call it 'my_code.tests.lua').
3. Edit 'my_code.tests.lua' (example template below)

--- my_code.tests.lua Code --------------------------------------------

-- Some super function to test
function my_super_function( arg1, arg2 ) return arg1 + arg2 end

-- Unit testing starts
require('luaunit')

TestMyStuff = {} --class
    function TestMyStuff:testWithNumbers()
        a = 1
        b = 2
        result = my_super_function( a, b )
        assertEquals( type(result), 'number' )
        assertEquals( result, 3 )
    end

    function TestMyStuff:testWithRealNumbers()
        a = 1.1
        b = 2.2
        result = my_super_function( a, b )
        assertEquals( type(result), 'number' )
        -- I would like the result to be always rounded to an integer
        -- but it won't work with my simple implementation
        -- thus, the test will fail
        assertEquals( result, 3 )
    end

-- class TestMyStuff

luaUnit:run()

--- Code End -----------------------------------------------------------------------

Execute the test code.
Add your tests and assumption checking.
Fix what's broken.

Understand more

• http://phil.freehackers.org/programs/luaunit/
• http://lua-users.org/wiki/UnitTesting

GUIDE: TDD unit testing tools for Tcl

As promised in http://shloemi.blogspot.com/2011/03/tdd-tools-for-tcl.html here is my experience with tcltest package and eclipse.


The story
Suppose we have a function called 'bits_serialize'.

This function should serialize a given data into bits_per_io bits per package (for examples see the tests below and what they return).

This function have the following signature:  bits_serialize {bits_per_io description}, where:

• bits_per_io
• How much bits each package have.
• description
• a pair of {data bits}, where:
• data 
• the data we want to serialize.
• bits
• the size, in bits, we want to serialize this data.

let's test this function using tcltest...

Test code

# Generated using http://pygments.org/

source unit-under-test.tcl ;# contains the definition of bits_serealize 

test base--always-ok {This is as simple as it gets.} -constraints {
} -setup {
} -body {
 return TRUE
} -cleanup {
} -result TRUE

test bits_serealize--partial-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x01 16 "]
} -cleanup {
} -result [list 1]

test bits_serealize--full-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0xFFFFFFFF 32 "]
} -cleanup {
} -result [list [ format "%u" 0xFFFFFFFF ]]

test bits_serealize--over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 64 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ]]

test bits_serealize--way-over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 320 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ] 0 0 0 0 0 0 0 0]

test bits_serealize--cross-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFF 1
  0xFF 2
  0xFF 3
  0xFF 4
  0xFF 6

  0x04030201 32
 "]
} -cleanup {
} -result [list [ format "%u" 0x201FFFF ] [ format "%u" 0x403 ]]

test bits_serealize--quanta-and-half {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFFEEDDCCBBAA 48
 "]
} -cleanup {
} -result [list [ format "%u" 0xDDCCBBAA ] [ format "%u" 0xFFEE ]]

eclipse-unit-testing

Results

++++ base--always-ok PASSED

++++ bits_serealize--partial-quanta PASSED

++++ bits_serealize--full-quanta PASSED

++++ bits_serealize--over-quanta PASSED

++++ bits_serealize--way-over-quanta PASSED

++++ bits_serealize--cross-quanta PASSED

++++ bits_serealize--quanta-and-half PASSED

My impression 

I definitely recommend using this unit!! and to my surprise eclipse supports it built in (see picture ==>).

GUIDE: tclunit/TDD for Tcl, usage and examples.

As promised (tdd-tools-for-tcl.html) here is my humble experience/research with tclunit.

Guides / tutorials found

• Getting Started with tcltest
• tcltest Part 2 – Multi-Module Test Suite

Research results

• Your first tcltests
• CREATING TEST SUITES WITH TCLTEST

Usage example

• http://wiki.tcl.tk/14465 explains it very good.
• See '> So, if the tests and the ...' section and below.

Have fun...

TDD unit testing tools for Tcl

After committing my first 'big' feature to my current employee, I got a feeling that something was left behind in the heat of the rush. That think was, of course, the new code test coverage.

That lead me to try and find tools / guidance for Tcl TDD.

Here are the things I've found for Tcl:

1. A very good TDD tutorials found
1. http://www.agiledata.org/essays/tdd.html
2. http://geosoft.no/development/unittesting.html
2. TDD tools for Tcl
1. Wiki comparison of available tools for Tcl -  http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Tcl
2. tclunit - http://www.tcl.tk/man/tcl8.4/TclCmd/tcltest.htm
1. Download here - http://sourceforge.net/projects/tclunit/

Thats all, not much. I intend to check tclunit, experience with it and report back later on... see Y'a.

UPDATE
As promised - http://shloemi.blogspot.com/2011/04/guide-tdd-unit-testing-tools-for-tcl.html