Test

Test Driven Development (TDD). Is a software development process that relies on the repetition of a very short development cycle.

Black-box Testing. Test the functionality of a component. Tests are written based on application requirements and specifications, which describe the expected output values for a range of given input values, and with no knowledge of the internal structure of the tested component.

White-box Testing. Full knowledge of the component internals.

Unit testing. Small, fast and independent tests to verify only a “single piece” or unit of the application. Can be considered both white and black box testing. Unit test are multi-user by default.

Unit tests are small, fast and independent tests and should be designed to verify only a “single piece” or unit of the application. When unit testing an appplication and its database, try to decouple the two as far as possible. For example use a mock object framework and applying principles such as Inversion of Control (IoC) and Dependency Injection to the application design, this way we can create mock objects that simulate the real database access interface, so we can test the database access part of the application without actually connecting to a database. This saves time.

Mock Objects. In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.

Reasons for use

In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is impractical or impossible to incorporate into a unit test. If an object has any of the following characteristics, it may be useful to use a mock object in its place:
supplies non-deterministic results (e.g., the current time or the current temperature);
has states that are difficult to create or reproduce (e.g., a network error);
is slow (e.g., a complete database, which would have to be initialized before the test);
does not yet exist or may change behavior;
would have to include information and methods exclusively for testing purposes (and not for its actual task).

For example, an alarm clock program which causes a bell to ring at a certain time might get the current time from the outside world. To test this, the test must wait until the alarm time to know whether it has rung the bell correctly. If a mock object is used in place of the real object, it can be programmed to provide the bell-ringing time (whether it is actually that time or not) so that the alarm clock program can be tested in isolation.

Integration and Acceptance Testing. Full system testing. This test how the small units (unit test) work when put together. This is usually automated as part of a continuous integration process. Acceptance testing tests how the application will be used by the end user and is usually performed by the Quality Assurance (QA) people. The two types of testing are very similar, but whereas integration testing is automated, acceptance testing is mostly performed by hand.

Stress testing databases. Microsoft SQLIOSim test I/O disk subsystem. Microsoft OStress part of the RML utilities for SQL Server, run SQL scripts simulating multiple users.

Error Testing. Transact SQL TRY…CATCH blocks.

Reasons for avoid testing:

  • we’re on a deadline and this will take too much time
  • we write good code
  • we can’t afford to spend more money for tests

Reasons for testing:

  • for developers: Running test in your code can clearly demonstrate that the problem lies elsewhere. Who’s responsible?
  • for managers: By testing our code we are substantially reducing future costs associated with bug fixing, refactoring and so on, at the expense of a smaller increase in development cost.
  • for end-users: Reduce the features list. Fewer features, but all working well

Source: Wikipedia and SQL Server Team-based Development Chapter 5: Testing Databases

Advertisements
This entry was posted in Testing and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s