re: unit testing. functional testing, system testing
Unit and functional tend to blend together.
System testing / Integration testing tend to go together as well.
Everything I have done and read says that "unit" testing should be done close in time to when the code is written.
close = same day or next day.
Lots of doc shows that testing gets more difficult, more time consuming, less accurate for every day after the code was written.
Honestly - I cannot quite get into the spirit of doing TDD tactical�� testing first, I like to do it shortly later.
Acceptance tests and Criteria tests - I like to do those first.
Alas, I am a printf kinda guy, so those get removed for production.
that is why frameworks are important for larger projects.
re: Work towards the middle
the big picture should be top down.
Building should be bottom up.
Building code from bottom up towards the objectives (older form of TTD anyone?)�� tends to work better.
Building with tested solid components.
re: Pair Programming / pair testing / Pair testing and development
When it works, it works great.
When it doesn't -- leaves a sourness. <grin>
It tend to be dependent on personalities of people trying to do it.
The XP croud and Agile croud push it.
when tend to be a younger bunch - in body or mind.
Also, older people tend to want their space.
Pair programming also exposes MANY warts
personal and programming.
not bad if you can handle it.
I love the idea of frameworks.�� And am learning more about them.
I do a LOT of printf style testing.
this works for me but for a larger project they should be probably more formal and repeatable.
PHPUnit looks exciting.
Selenium as well.
If you are more than one on the project.
Agile's stand up meeting meets the 90 - 10 criteria.
If you do nothing else from agile
do the "stand up"
for a min or three - the three questions!
what did you do yesterday.
what is in your way (why didn't you do it, or why can you not do something)
what are you doing today?
re: Agile and DONE - not DONE, DONE, DONE.
There are lots of fancy essays along this line
here's one that popped up on radar today: http://jrothman.com/blog/mpd/2010/08/what-should-done-mean-coda.html
The essence is:
What is DONE for this job.
And what is the job.
Too many times a developer will tell a manager or an owner
.. I have to do, this , that , the other thing
Usually they mean that they got their function completed, and want some kudos, but
they did not do (anyone of a number of things)
It destroys credibility.
Can destroy moral.