Re: Unit Testing Non-Believer
From: Erwien Saputra (erwien_at_nospam.codeilne.dot.net)
Date: 12/21/04
- Next message: Erwien Saputra: "Re: Unit Testing Non-Believer"
- Previous message: Richard Grossman: "Re: Delphi 2005: Beautiful packaging"
- In reply to: Jeffrey A. Wormsley: "Re: Unit Testing Non-Believer"
- Next in thread: Jim Cooper: "Re: Unit Testing Non-Believer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 20 Dec 2004 19:01:24 -0800
Jeffrey A. Wormsley wrote:
> I was wondering how people used unit tests with database code and
> exceptions.
I did not test with database code. I test Delphi code that performs
action to the database.
> For instance, how can you tell if your code handle DB
> errors that are thrown as exception correctly?
When I write my unit test, I create tests that I expect to pass, before
I tried to break my own code, I have to make sure it behaves correctly.
After I make sure that my code works if it has the desireed
environment/parameters, then I tried to break it. If the input is
totally wrong, I do expect exception.
Given a valid input, any exception is most likely a bug.
> Do you have to force
> your DB engine to throw an exception, and if so, how can you do that?
I test only the code that I write, I do not test or look for exception
that the engine, OS, or Delphi throws.
> Do you make your own TDataset descendent to drive the code under
> test, so you can throw arbitrary exceptions at your business code?
No. Let says that I have a billing application. I want to test my
routine that receives a customer ID and calculates the total due for
that customer.
Instead of using any records available at that time, my unit test will
create a customer, creates invoices with predetermined amount, and then
call the routine to calculate total due for that customer. If
necessary, I often hard-coded the returned value. If the value match, I
know the routine works correctly.
Database got updated/modified all the time, especially if you work in a
team. You cannot rely for a specific environment to exist. That was
what I meant by the class helpers. It help creates the environment
that I desired.
My class helper is just a bunch of classes that got called at the Setup
method in DUNit. It reads a SQL file, execute its content to the
database. And executes another SQL to clean that data at the TearDown
method.
> Everyone says that UI code isn't really suitable, presumably because
> you can never tell when or what the user is going to do. Will they
> click this control, then that one? Or vice versa? When more than a
> few controls are available, then the combinations are staggering, and
> there is no way you can test them all. I would think exceptions
> would be eqaully difficult to test, because you would need to be able
> to generate any of a multitude of exceptions in any of a multitude of
> places, and the number of combinations would be unmanageable.
I am not sure how to test UI effectively with unit test. That area is
for tools like WinRunner or AutomatedQA. unit test works great for
reusable classes, and non-UI logic.
As the developer, I have the advantage of knowing the internal logic
when testing. I know how to create test plan that traverse every
possible path in the code. But the test is getting more complex with
every 'if', 'while', 'repeat'. As you said, UI has way too many
variances, and often the action triggers an update, or pop-up a dialog.
Those are hard to test with unit test.
Other good things about unit test, it is good for acceptance test and
to validate the business rules/logic.
Wien.
-- http://blogs.slcdug.org/esaputra
- Next message: Erwien Saputra: "Re: Unit Testing Non-Believer"
- Previous message: Richard Grossman: "Re: Delphi 2005: Beautiful packaging"
- In reply to: Jeffrey A. Wormsley: "Re: Unit Testing Non-Believer"
- Next in thread: Jim Cooper: "Re: Unit Testing Non-Believer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
