Showing posts with label test driven development. Show all posts
Showing posts with label test driven development. Show all posts

Monday, July 6, 2015

Ways to understand an software application

Generally , When we are given a legacy application for our own understand and later to fix the bugs. We tend to follow the ways as below
  1. Open your application and start go through application UI
  2. Open the source code and go through each files to get an understand of application structure  
  3. Create the classes diagram using Visual Studio/IDE
  4. Open any documents(requirements ,help .. etc) related to the application and try to understand them
  5. Debug the application using IDE.
Issues /Pitfalls with the above approach.
  1. if you follow way 1 merely, It tends to be more of manual testing and helps a little
  2. if you follow way 2 and 3, it is not much of any help
  3. if you follow way 4 , In my view , Writing documents are kind of violation of the principle"Don't repeat yourself " and Generally gives what application is supposed to do and not what application is doing right now(we are interested in knowing this)
  4. if you follow way 5 , It is more of waste of efforts and time
My recommended ways to understand any application.
  1. Open your application,start go through application UI to get sense of how application looks like
  2. make a list of unknown words/terminologies to make sure we get little bit of domain knowledge
  3. Get to know about those words/terminologies by going through the documents/asking someone else/ Google them
  4.  try to understand your technical design documents if you have.
  5. Make a list of most critical functionality based on your present understanding(e.g. CRUD)
  6. Make a list of classes and discover their responsibility corresponding to the listed  in step 5
Follow the below steps for each of classes listed in the step 6
  1. Make a list of the keywords(language specific) which you don`t understand in the class
  2. Understand all keywords
  3. Break dependencies in the class/public methods involved
  4. Write characterizing unit tests (are tests that characterizes the actual behavior of a piece of code) based on your understandings of class/method responsibilities   
  5. Make sure that you have clear intention to get sense of what this does actually not to find any bugs 
  6. debug this unit test by seeing through every line of code and DB activity if any
  7. Stop when you feel that you got a sense of responsibilities the class has 
By following the steps above, We can get more confidence while working with a legacy application

Thursday, June 18, 2015

Wrap approaches when you are adding new features/ modifing the existing features in a legacy application

Wrap method:

Suppose we have Employee class which does pay the salary to employee  as below.
And all of sudden there is a change requirement to log employee information into the database/file
The same thing can be achieved in a bit different way without changing the pay method and
 introducing the new method as below

Wrap Class :  is nothing but decorator patterns.In this case, the same new requirement can be implemented as below.

Wednesday, June 17, 2015

Sprout approaches when you are adding new features/ modifing the existing features in a legacy application

     The sprout approaches is one of approaches which helps us when we are changing a legacy application and use these approaches with cautious.

Used when:
  1. you do not have much time to get the class under test harness 
  2. these new changes are to be get under test harness
  3. you want to develop these changes/method in test driven development
Types
  1. Sprout Method
  2. Sprout Class
Sprout Method : Steps to implement this type
  1. Identify where you need to make your code change.
  2. If the change can be formulated as a single sequence of statements in one place in a method, write down a call for a new method that will do the work involved and then comment it out.
  3. Determine what local variables you need from the source method, and make them arguments to the call.
  4. Determine whether the sprouted method will need to return values to source method. If so, change the call so that its return value is assigned to a variable.
  5. Develop the sprout method using test-driven development.
  6. Remove the comment in the source method to enable the call.
 Tips to get a new method under test harness
  • If the constructor is having bad dependencies, then try to pass the null values 
  • If passing null values to the constructor does not work, make that method as static.
Sprout Class : This type should be used  when the you can not get the new method under test harness even after the passing null values to the constructor and you can not make the new method as static.
Steps to implement this type as follows.
  1. Identify where you need to make your code change.
  2. If the change can be formulated as a single sequence of statements in one place in a method, think of a good name for a class that could do that work. Afterward, write code that would create an object of that class in that place, and call a method in it that will do the work that you need to do then comment those lines out.
  3. Determine what local variables you need from the source method, and make them arguments to the classes' constructor.
  4. Determine whether the sprouted class will need to return values to the source method. If so,provide a method in the class that will supply those values, and add a call in the source method to receive those values.
  5. Develop the sprout class test first.
  6. Remove the comment in the source method to enable the object creation and calls.