hasan's blog (বল্গ)

hi,
just jotting down all my thoughts what we partially discussed today at coffee with sqabd session.

why unit test (a developer perspective) ?

when we (developer) code we need to spit out some information to verify certain point of function/logic to ensure they are returning or working as the way they suppose to behave.

for example –
def convert_to_taka(p_dollar)
  return p_dollar * get_current_taka_conversion_rate()
end

def get_current_taka_conversion_rate
  # let’s say, this function retrieve this value from remote web service call
end
as you can see “convert_to_taka” function is not all in all, it has dependency to another method where it delegates it responsibility to get the current currency rate for taka.

so as a developer my responsibility is not only to ensure convert_to_taka method also my responsibilities include to verify whether get_current_taka_conversion_rate is behaving properly.

so before i was introduced with test first approach. i used to write my code in the following manner -
def convert_to_taka(p_dollar)
  logger.debug(“converting dollar #{p_dollar} to taka”)
  conversion_rate = get_current_taka_conversion_rate()
  logger.debug(“conversion rate for taka – #{conversion_rate}”)
  return p_dollar * conversion_rate
end
so during my development process i had to watch these logging outputs with my eagle eyes so that nothing could get out my concern.

why test first development ?

as you can understand from the “test first development approach”, it reflects something has to be upfront.
without developing we can’t test what is going to be developed, but using test first approach it means you are preparing your expectation upfront to get your code working with your expectation. so here what i would have written if i knew test first approach before.

def setup
  # mock currency retrieval web service or whatever requires to set 70
  # as the returnable value from get_current_taka_conversion_rate()
end

def test_should_successfully_convert_currency_with_valid_input
  assert_equal(7000, convert_to_taka(100))
  assert_equal(525, convert_to_taka(7.5))
end

similarly you could have the following test cases
def test_should_fail_to_convert_currency_when_webservice_returns_error; end
def test_should_fail_to_convert_currency_with_negative_value; end

so if you compare this with the above statement where i mentioned “logger.debug” related stuffs.
you can see the difference where this one is more understandable for us to re imagine what our task means to us.
this approach would give us chance to rethink about the task we have chosen (if agile team).

why it has nothing to do with tester test ?

test driven development is for developer to do his/her job properly to ensure better code (less bug) according to his task definition
eg. user stories
as a developer
i want to see my function is working while currency web service is not returning anything

or perhaps

as a developer
i want to see my function is taking last known currency exchange rate from cache data while currency web service is failing.
or perhaps

as a visitor
i want to convert my currency by clicking on “convert currency” button

or

as a visitor
i want to convert my currency without refreshing the whole page….

this has nothing to do with 1px design issue, or notification message doesn’t appear immediately or problem from user kinda tester point of view. still we need them badly to bet on burger per bug

so i think i could make sense why it won’t worth anything if tester prepare the test case for developer :p

TDD is to verify our own code
(because client changed his mind, or because we need to support another scenario)

when requirement changes or adds new scope, we have to review our own code to enhance the scope.
here comes compatibility issue, as you can understand old test cases would become the more kissable asset to verify our recently modified code against the old requirements and new requirements. (perhaps some function requires old way to do the job)

TDD is enabling us to run continuous integration and build process

as you can recall what sajjad bhai was mentioning about continuous integration and warning for those (developer) who break the code.
using these developer created test cases we can do this job.
or perhaps we can employ our testers (hardly a few) those who LOVE (or forced to love) to write integration test case.

anyway, thanks for nice afternoon with mouth watering pizza and coffee, wish to see more pizza slices
best wishes,