My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
NonUnitTests  
Description of non-unit tests that should be done
Updated Mar 25, 2008 by ricardov...@gmail.com

Introduction

Since Kinti is a distributed framework, some things are hard to test through unit tests. Some things should simply be tested by a user. This page describes a number of functional tests that should be done regularly during development.

Any order startup

Reason

The different components of the system (configuration, runner and buckets) must be able to start in any order and still work properly.

Implementation

Some components of the system make their presence known over the pubsub node. Also, if a certain component is not online, the other components will simply wait until it is present. Untill that time they should not do anything that could possible cause errors.

Test

Test this by starting up the components in every possible order. Since the configuration server isn't broadcasting it's presence non-stop, it might take a minute or so for the components to connect to each other.

Unexpected disconnects

Reason

The system in total may not crash when for any reason the connection to each other drops.

Test

This can be tested by shutting down anything that is required for the components to connect. We could try each of the following with a completely started system:

  • Shutting down the Openfire server
  • Killing the kinti sessions in the Openfire server
  • Shutting down the network connection of the server any component is running on - neatly
  • Shutting down the network connection of the server any component is running on - rude
  • Killing the Configuration server
  • Killing the Runner
  • Killing the Buckets
  • Changing the configuration files to contain invalid content

Erroneous plugins

Reason

Since the user can make his own plugins, this could cause problems. When loading a erroneous plugin, the system should not crash or freeze, but give a warning message and continue normally. A plugin may also not change the way the framework works.

Test

The following things should be implemented and run to test what is mentioned above:

  • A plugin containing a syntax error
  • A plugin raising random Exception
  • A plugin returning erroneous results
  • Perhaps: a plugin that tries to change settings of the system
  • A plugin that freezes or does not stop
Powered by Google Project Hosting