Tag Archives: testing

JMock – Lessons learned

  • Expectations are asserted after the run of each test method
  • Expectations are additive, so remember to call mock.reset() if you are planning to set a new expectation in each test method
  • If u r using JUnit 4 and above then you no need to extend from MockObjectTestCase. You can use @RunWith(JMock.class). But that means we can not use other JUnit 4 runners like @RunWith(Parameterized.class). You can look into XJ4 (extensions for JUnit 4) project @ http://code.google.com/p/peachjean/wiki/XJ4 to see how it can help
Advertisements
Tagged ,

JMock – mocking the same interface multiple times

A subject can have multiple addresses which i wanted to mock. but the below attempt throws the fololwing error
java.lang.IllegalArgumentException: a mock with name tokenizedUnitedKingdomAddress already exists

UnitedKingdomConsumerSubject primarySubj = context.mock(UnitedKingdomConsumerSubject.class);
TokenizedUnitedKingdomAddress currAddr = context.mock(TokenizedUnitedKingdomAddress.class);
TokenizedUnitedKingdomAddress prevAddr = context.mock(TokenizedUnitedKingdomAddress.class);
TokenizedUnitedKingdomAddress prevAddr2 = context.mock(TokenizedUnitedKingdomAddress.class);
 
primarySubj.setAddress(CURRENT, currAddr);
primarySubj.setAddress(FORMER, prevAddr);
primarySubj.setAddress(SECOND_FORMER, prevAddr2);

Seems like we have to use the overloaded method public T mock(Class typeToMock, String name). So the below fixed the error

TokenizedUnitedKingdomAddress currAddr = context.mock(TokenizedUnitedKingdomAddress.class, "current address");
TokenizedUnitedKingdomAddress prevAddr = context.mock(TokenizedUnitedKingdomAddress.class, "former address");
TokenizedUnitedKingdomAddress prevAddr2 = context.mock(TokenizedUnitedKingdomAddress.class, "2nd former address"
Tagged ,

How Google Tests Software key points

I have pre-ordered the How Google Tests Software hoping that it would be as good as a read as How We Test Software at Microsoft. I have completed reading in a week and I didn’t see any common content. Both books talk about different things and How We Test Software at Microsoft is still my favorite. While How We Test Software at Microsoft identifies various formal techniques or approaches for testing, the How Google Tests Software is more about the Google perspective of quality assurance, how it is different and why they approached it that way. It has lots of interviews with the Google’s TD (Test Director), TM (Test Manager), TE’s (Test Engineer), SET’s (Software Engineer in Test) and SWE’s (Software Engineer). Anyways below are some of the key take aways

  1. Quality is everyone’s responsibility.
  2. Hiring practices should change so that resources with programming skills are hired.
  3. Automate wherever possible so that most of the resource time can be spent testing usability etc.
  4. Exploratory testing and crowd sourcing.
  5. Software can never be bug free so release often to limited user base for better feedback.
  6. Author tests in the language the application is written.
  7. Do not enforce enterprise wide standards as that would limit innovation. (But I believe this is only true for companies whose hiring practices makes sure that skilled resources are hired).
  8. Opportunity given to resources to work 20% of their time on the projects they are passionate about.
  9. Open rotation policy. Resource is free to move to any project within Google after 18 months.
  10. New hires encouraged to start with testing.
  11. And of course continuous integration.

Programmer Fun

enter image description here

Old India Photos - Jhansi Fort in 1857

My Country, My People (Jhansi Fort in 1857)

Tagged ,