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

87261Re: [XP] re: XP, unit testing and accepted failures

Expand Messages
  • Gary Brown
    Jan 1, 2004
      --- In extremeprogramming@yahoogroups.com, yahoogroups@j... wrote:
      > From: "Sean Gilbertson"
      > <smogallstar.at.yahoo.com@y...>
      > Sent: Wednesday, December 31, 2003 8:16 PM
      > Subject: Re: [XP] re: XP, unit testing and accepted failures
      > > By handle, for example: I surround a "connect( )"
      > > in a try block, and connect throws a
      > > "CouldNotConnectException" (or something. In this
      > > scenario, the function fails and either propagates
      > > the exception or returns something unexpected or
      > > unwanted. If you wrote a unit test that ensured that
      > > something was received off the socket, that would fail
      > > the unit test.
      > > - Sean
      > I see what you're saying. You're trying to test
      > exception handling. The easiest way to do this
      > is to mock it out so that you don't call connect()
      > directly. You have your own proxy for the
      > library calls. Then you can set up the mock to throw
      > an exception on the test for whether the exception
      > handler works, and to simulate a connection on
      > the tests where you want to test that function.
      > The last time I had a network project, I did that
      > and it cut my test time way down.
      > Where this gets messy is, of course, the question
      > of whether the mocks are actually modeling the
      > live environment properly. For that test, I'd put
      > a simulator on the other end of the wire so I could
      > force the error conditions I wanted when I wanted
      > them.
      > John Roth


      Adding to John's experience ...

      A couple of years ago, I worked on a project for a music and video
      distribution warehouse in Indianapolis. The purpose of the project
      was to utilize a couple of surplus USPS flats sorting machines (FSM-
      881s) to presort the out-going product, to get a better postage
      rate. Part of the project was to provide a real-time display of the
      sorting operation, e.g. throughput, percent complete, audit trail,
      missing mailpieces, etc.

      The "dashboard" was a VB6 app, connected to the FSM-881s with a null
      modem serial cable. When properly configured, the FSM-881 will send
      a psuedo-xml data stream through the serial line to the listener.
      All of the physical mailpieces had three barcodes, postnet code,
      planet code, and order number. As the FSM scanned each package, it
      would decide what sort bin the package belonged in and send it down
      the raceway. When the package arrived at the appropriate bin, a big
      blue finger would knock it off the track and into a collection bin.
      The FSM would then send a <mailpiece postnet="99999999999"
      planet="99999999999" /> element to the serial connection. There were
      many other element types in the data stream, which were mostly
      ignored. There was no connection protocol, just open the COM port
      and start parsing.

      The FSM-881s are 70s technology. They are about 100 feet long by 20
      feet wide. The on-board control computer runs Q-NIX, all of the
      control code is written in C. Sometime in the late 80s, the control
      computer was upgraded to a 286, and remains so today. The machine
      runs great most of the time, except when it doesn't ...

      Anyway, I needed a way to test this data stream in my VB6 app. I
      strung a null modem cable between two PCs, one acting as the control
      computer and the other acting as the listener. On the control
      computer, I wrote a small VB6 app that allowed me to select a test
      case and transmit the data to the listener. There were many test
      cases that covered the positive path, plus every possible error
      condition, including dropping the connection, sending invalid
      mailpiece elements, incomplete mailpiece elements, etc. Most of the
      test cases simply opened a text file and transmitted the contents,
      others were more complex.

      On the listener, I wrote another small VB6 app to consume the data
      stream and display the parsed data in a large testbox. I did that,
      so I could learn about collecting data with this mechanism. Using
      that knowledge, I then added the data consumer code to the dashboard
      app. Over time, I added code to the test driver on the control
      computer to read the application's mailpiece database to simulate a
      complete production run. This allowed me to fully exercise the
      dashboard display and to do performace and capacity measurements.

      Gary Brown
      Salt Valley Software Services
      Lincoln, NE
    • Show all 10 messages in this topic