Thursday, July 22, 2010

Test Driven Development


Five key principle questions must be asked all time:
  1. What Do I Want to Accomplish?
  2. Does It Do What I Want?
  3. Does It Do What I Want All of the Time?
  4. Can I Depend On It?
  5. Does It Document My Intent?
TDD Process Itinerary
  1. Obtains Project Specification Documents to identify specification needs, usually the action from the UML CASE diagram. (What needs to be done?)
  2. Write the test procedures and test methods (Unit Test) to enforce it achieve the specification needs as how it was documented in Project Specification Document. (Does it do what I want?)
  3. Write the code just to pass the test.
  4. Ensure and maintain the tests from never fail at all times. (Does it do what I want at all time and Can I depend on it?)
  5. Re-factor the code for readability and maintainability, while ensure the tests remain intact to the specification. (Does it document my intent?)

Few ways to achieve unit testing: -
  • Dummy
  • Fakes
  • Mocks
  • Stubs
To be continue...

Top 10 Unwanted Characteristic of a Developer

1. Egoness
Example: -
We are senior and we have many years of exposure and we know what we need to do, please keep your explanation to yourself.
Outcome: -
Fail to grow as a team, fail to deliver or deliver with ULTRA high defects. Copying design ideas from others but not bothering to ask and resulting in sub-standard code, but proclaiming that is the beauty of it when challenged.

2. Year-istic Mathematician
Example: -
I want a lead role because of my many years of exposure. I work with many big profound companies and I derserved the lead role.
Outcome: -
Not able to justify the pros and cons and delivering sub standard work or not delivering at all.

3. Favor Quick Wins over Quality
Example: -
Deliver the max within the shortest time is the primary concern of the company to make money. Patterns and design are purism and that often complicates the development.
Outcome: -
Fails to grow as a team or individually. Produced sub standard codes that needs major rework whenever enhancement needs imposed.

4. Never Admit Own Mistakes
Example: -
The bugs had happened because the calling function never do a parameter validation and error checking.
The late delivery was largely due to inconsistent and or incomplete requirements.
Outcome: -
Never learn from mistakes and similar problems reoccuring over and over again. It is quite clear that if it is not your problem but it somewhat impact your work delivery or team goals, it is everyone's problem and deal with it if you can, escalates otherwise.
To be continue....

.NET Application Slow?

Many people complained about .NET application being slow. First question first, do you know how .NET work internally?

Pickup a good book like CLR via C# (Jeffrey Ricther) or Framework Design Guideline (Cwalina, Abrams) would help.

If you don't understand how GC (Garbage Collector) works, please do yourself a favor.

If you find yourself writing lots of codes (and redundant codes), do yourself a favor reading Design Patterns.

If you find yourself adding lots of project/assembly references into a project, do yourself a favor reading books about SoC (Separation of Concern or Single Responsibility or Architectural Consideration).

If you find yourself fixing lots of bugs that subsequently introduce more and more bugs (defects), change your development engineering process but adopting TDD (Test Driven Development) approach. (Unit Testing)

I'm hoping to have touch more indepth details of these topics in the coming post.