locked
Product Testing Approach RRS feed

  • Question

  • I am not sure if i have chosen the best forum category but i need to have some thoughts around the best approach we can use around the product testing.

     

    Here's our testability requirement.

     

    We have two component of our product say 'C' & 'R'.  My team is involved in managing the component 'C'

     

    The component 'R' is built over the 'C' and is managed and tested by a different team. 

     

    To test the components and the API provided by 'C' we need the 'R' component which is where our test environment is getting into trouble. We want to use a centralized environment to test it but there are pieces in the application which at times require same configuration to be used differently ( one tester want 'ABC' as some configuration for his/or her test and at the same time the other guy may require the same configuration to have a different value). This can’t be done to the product 'C' until and unless we have 'R' setup locally on each tester’s machine, which is what we are trying to avoid. To keep the testers machine as light as possible.


    Bikrant
    Thursday, June 30, 2011 9:46 PM

All replies

  • Hi Bikrant,

    Basically what your looking to do is mock out the 'R' component. Thing is I'm not completely sure what that will involve, could be a lot, as it all depends on the interface between each component, how loosely coupled the two components are, and how they communicate with each other.

    Using a database as an example then for testing purposes the whole server database can be mocked out using an in-memory database, speeds up the tests and can be thrown away easy and configured in different ways... sounds good... but the reality of the situation is that it all depends on how the application interacts with the database, the interface between the application and the database, the communication mechanisms, and so on.

    You have to look at the interface between the two components, and see if component R can be completely replaced in C without effecting how C works. Loosely coupled. Then you can inject any number of mock 'R' components with different configurations and that act in different ways depending on circumstance.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Friday, July 1, 2011 7:31 AM
  • Yep.

    Mocks or stubs.

    You essentially need something which can input stuff matching your different configurations.

    Since this is just for testing you can have a different thingummy per configuration if that's easier.

    Hopefully someone thought of this and the two components aren't too tightly coupled.

    If they are then you may need to refactor somewhat, if that is possible.

     

    As derek says injecting a mock component is fairly standard stuff if R is a service or something you need a reference to and you can read up on inversion of control.

    You will want a mocking framework of some sort like moq or unity.

     

    If R just uses C for whatever and refers to it rather than the other way round then write your own stub as a substitute for R.

    Friday, July 1, 2011 9:21 AM
  • Hi yeah agree with Andy agreeing with me :) just going to expand on it a bit....

    The choice between using a mocking framework or creating your own 'mock' object. What is preferred.

    Well Mocks can be a bit complex to set up. Once the mock is created you then need to code the mocks behaviour... now that could be a lot of work... it depends... creating your own mock from implementing the same interfaces that are on R has a feeling on being a lot of work but it might be a cleaner option than a mocking framework. Depends on the complexity of the object being mocked.

    Mocking something at the class level for unit tests is manageable... when you go for something like mocking a whole service it might be different.

     

    Ok what I'm saying is yeah look at mocking frameworks for sure but look forward and balance it against the option to code your own mocks.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Friday, July 1, 2011 10:17 AM