Loading ...
Sorry, an error occurred while loading the content.

Re: IS agenda testing patterns

Expand Messages
  • JeffGrigg
    In my experience of retrofitting tests into legacy code, I find it helpful to think of the system having a stack of layers like this: 0. The user 1. Views 2.
    Message 1 of 8 , Jan 20, 2010
    • 0 Attachment
      In my experience of retrofitting tests into legacy code, I find it helpful to think of the system having a stack of layers like this:

      0. The user
      1. Views
      2. Presenter/Controller
      3. Business Logic
      4. Data Access Objects
      5. Database / data store

      There are useful tools, like Selenium, that will test the whole stack. But they're slow and brittle, as the system changes.

      So I end up writing mocks/fakes for the top and bottom layers (1. Views and 5. Database) and testing everything in between (2 thru 4).

      Use weak Singletons (instances replaceable by test code) and possibly factory objects stored as Singletons to mock the lowest levels -- particularly when they're called through static functions. It's unpleasant, but it gets the tests working. And you can refactor the Singleton-ness out later, as needed.


      --- "strazhce" <infobox.oleg@...> wrote:
      > - controller API is very advanced, with strict separation of
      > View from MC, but also complex at the same time

      This sounds like good news: If well separated, then you should be able to mock the view layer easily.

      > - certain validations/controller API calls are tied to GUI
      > transitions and events generated from there - we would
      > have to fire those events manually in tests

      Yes, you'll have to simulate GUI events from your tests.

      > - our current skills and application related utilities for
      > unit testing are not very good. We would have to change
      > testing paradigm of the team from GUI oriented testing
      > to something else, that's hard. [...]

      Look at it as on opportunity to learn. And don't think you're limited to just one paradigm: You can have unit tests, integration tests and acceptance tests all working together to test a single system! I'll often have mock-based integration tests that display no GUI and do not hit the database, and also run Selenium tests against the full stack, with GUI and test database. You can do more than one thing. And during transitions, you'll have to.

      > Is it common to create another layer around controller for
      > unit/integration testing purposes, to simplify things?

      I say mock the view. Use the real controller and business logic. Mock the view and the database.

      Thank you for the questions! We're all glad to help!
      - jeff
    Your message has been successfully submitted and would be delivered to recipients shortly.