Haal...

about 3 years ago | Sukhpal Bhatti: life

Duniya ki is bheed meinHum hamesha tanha hi jiye,Duniya ne to hamesha khushiyaan hi diJitne aansoon hain sab apni hi tamanna ne diye

:-))

about 3 years ago | Surbhi Bhati: Clean Desk, Jammed drawers

When you are born,

Your world is so small

Mother’s lap & father’s shoulder

Is all you know of.

And then you grow up

Startled that the business of life is very mean

And before you realize

You are turned into a machine.

While you make money, drink, dance

and chill out

all you hear is noises

and Voices die out.

You don’t even know how long you’ve been pretending

Being a person, you never thought of

So why not once be your innocent self

And damn the showing of

We always portray what we wanna be

We never cherish what we actually are

We become a person of other’s want

And our true self stands far

So being yourself is not that bad

It’s mighty hard I agree

but it may well turn you on

and stand on top and bounce and flee!!!

How I refine a test spec while writing getting it to green

about 3 years ago | Alex Rothenberg: Common Sense Software

In most of the examples I've read on TDD they show the Red-Green-Refactor cycle as

1. 
   
2. Write a failing test
3. 
   
4. Write just enough code to make the test pass
5. 
   
6. Refactor
7. 
   
8. Repeat
9. 
   

I absolutely do believe in this cycle and live it every day however I think there's a small detail that differs from what I do. When I move from step 1 to step 2, I keep my test window open and will switch back and forth between the test and code windows and refining the test while writing the code that makes the test pass. Its only as I write the code that I realize what calls I need to mock out in the test which also adds additional expectations to my test. I'm sure this is how most people work but I've never seen it written up so I'm going to try going through an example here.

Let's say I have a social networking application with a page showing friend requests where you can accept or reject each request. Something like this

Now I'm ready to implement an action in the Friend Controller that receives a posted form with a list of friend requests to accept and reject. I might first go into my friends_controller_spec.rb and write something like

describe FriendController do
  it 'should approve one friend requests' do
    post :update_requests, :approved_requests => ['123']
    response.should be_redirect
    response.should redirect_to(:back)
    flash[:notice].should  == "Friend requests approved."
  end
end

Now I have a failing test so I start implementing the code

class FriendController < ApplicationController
  def update_requests
    FriendRequest.approve(params[:approve_requests])
    flash[:notice] = "User access changes saved."
    redirect_to :back
  end
end

I'm done but my test is still failing...why? I haven't added the approve method to my FriendRequest model yet. I could go ahead and implement that method to get this test to pass but I don't want to do that because then this test would be testing more than just one unit. This is a unit test for the update_requests method of my FriendController and should be isolated from bugs in the rest of my application. Time to go back to the spec and add a mock to isolate this spec from the model and impose another expectation on my spec (that the method be called with the correct argument).

describe FriendController do
  it 'should approve one friend requests' do
    FriendRequest.expects(:approve).with(['123'])
    request.env['HTTP_REFERER'] = "http://some.site.com"
  
    post :update_requests, :approved_requests => ['123']
    response.should be_redirect
    response.should redirect_to(:back)
    flash[:notice].should  == "Friend requests approved."
  end
end

Now my spec passes and I can do my refactoring then go back to the beginning and write my next expectation.

The point of this example is that when I first wrote the spec I hadn't yet thought about how I would implement update_requests so did not yet know that I would need to mock FriendRequest.approve. I do this all the time and typically find myself go back and forth between the code and spec many times with the spec telling me what code I need to write and the code telling me how to refine the spec.

One last point (and a teaser for a future post). You have probably noticed that although my spec passes if I try to run the application it will not work because I still haven't written the FriendRequest.approve method. In a future post I hope to discuss how to interleave integration testing into this process to ensure that the classes we're writing in isolation also integrate so that the application satisfies its business function.

How I refine a test spec while writing getting it to green

about 3 years ago | Alex Rothenberg: Common Sense Software

In most of the examples I've read on TDD they show the Red-Green-Refactor cycle as

1. 
   
2. Write a failing test
3. 
   
4. Write just enough code to make the test pass
5. 
   
6. Refactor
7. 
   
8. Repeat
9. 
   

I absolutely do believe in this cycle and live it every day however I think there's a small detail that differs from what I do. When I move from step 1 to step 2, I keep my test window open and will switch back and forth between the test and code windows and refining the test while writing the code that makes the test pass. Its only as I write the code that I realize what calls I need to mock out in the test which also adds additional expectations to my test. I'm sure this is how most people work but I've never seen it written up so I'm going to try going through an example here.

Let's say I have a social networking application with a page showing friend requests where you can accept or reject each request. Something like this

Now I'm ready to implement an action in the Friend Controller that receives a posted form with a list of friend requests to accept and reject. I might first go into my friends_controller_spec.rb and write something like

describe FriendController do
  it 'should approve one friend requests' do
    post :update_requests, :approved_requests => ['123']
    response.should be_redirect
    response.should redirect_to(:back)
    flash[:notice].should  == "Friend requests approved."
  end
end

Now I have a failing test so I start implementing the code

class FriendController < ApplicationController
  def update_requests
    FriendRequest.approve(params[:approve_requests])
    flash[:notice] = "User access changes saved."
    redirect_to :back
  end
end

I'm done but my test is still failing...why? I haven't added the approve method to my FriendRequest model yet. I could go ahead and implement that method to get this test to pass but I don't want to do that because then this test would be testing more than just one unit. This is a unit test for the update_requests method of my FriendController and should be isolated from bugs in the rest of my application. Time to go back to the spec and add a mock to isolate this spec from the model and impose another expectation on my spec (that the method be called with the correct argument).

describe FriendController do
  it 'should approve one friend requests' do
    FriendRequest.expects(:approve).with(['123'])
    request.env['HTTP_REFERER'] = "http://some.site.com"
  
    post :update_requests, :approved_requests => ['123']
    response.should be_redirect
    response.should redirect_to(:back)
    flash[:notice].should  == "Friend requests approved."
  end
end

Now my spec passes and I can do my refactoring then go back to the beginning and write my next expectation.

The point of this example is that when I first wrote the spec I hadn't yet thought about how I would implement update_requests so did not yet know that I would need to mock FriendRequest.approve. I do this all the time and typically find myself go back and forth between the code and spec many times with the spec telling me what code I need to write and the code telling me how to refine the spec.

One last point (and a teaser for a future post). You have probably noticed that although my spec passes if I try to run the application it will not work because I still haven't written the FriendRequest.approve method. In a future post I hope to discuss how to interleave integration testing into this process to ensure that the classes we're writing in isolation also integrate so that the application satisfies its business function.

SAP PMO Lead - My new role

about 3 years ago | Bhargav Gandhi: AGILE SOFTWARE DEVELOPMENT

Project Management Office(PMO) is a new experience for me. This is managerial role. It deals with the consolidated and corporate view of "SAP as a platform" across my organization.

My respsonsibilites are

1. Managing corporate level SAP initiatives
2. Help/guide different verticals with their SAP related needs
3. Interact and co-ordinate with the SAP India/SAP AG.
   

There are some benefits associated with this role:

1. I get to interact with lots of people across the organization. This results in the increased visibility
2. Involvment in the pre-sales and proposals stage
3. Management experience in the field of IT