Discussion of tests for Storm

Magnity - August 10, 2009 - 14:46
Project:Storm
Version:6.x-1.x-dev
Component:Miscellaneous
Category:task
Priority:normal
Assigned:Unassigned
Status:active
Description

It seems accepted across Drupal modules now that tests are a good way of spotting if bugs are introduced into a module, or if a module breaks a different part of Drupal.

Therefore it would be useful to have a few tests written for Storm.

Lets use this issue to suggest and discuss tests that may be useful - and new particular issues for posting each test and the associated tracking of committing them to Storm.

#1

jalama - November 22, 2009 - 15:53

Seems to me we should start with the basics.

1.) Creation of each node type which is generally to say make sure all the form rendering happens correctly
2.) Tests that attempt to create nodes without required fields, making sure it's not allowed
3.) Creation of nodes without correct dependencies (ie try and create a time tracking without appyling it to a project/task/ticket, create a team without there being any people saved in Storm, etc..)
4.) Try and pass bad variables into functions (ie pass strings into # of days you have for billing)

Then move into testing the same things with different admin settings, ie create an invoice tax settings set to "do not apply" and make sure it is created, etc...)

Of course that could make for a lot of issues, if we do one issue per test.

#2

Magnity - November 22, 2009 - 15:56

Yes - a lot of issues, but the best thing will be that Storm ships with the tests attached. So individual issues will come and go as they are committed to CVS.

#3

jalama - November 26, 2009 - 13:02

On the CiviCRM project we spent time making sure it was easy to reset the databases so you knew each time what values you were starting with and you always had clean data. I'm thinking I 'll start be creating that logic.

So create a class with methods that does the following

  1. Truncates the tables for all active storm modules
  2. Populate active module tables new with sample data, being sure to create any dependencies (so if a project is created an organization is automatically created for the project to be linked to)
  3. The methods allow for the creation of multiple records (eg you can create multiple people so you can test assigning multiple people to a team)
  4. Allow for the default values to be overridden easily in the respective method calls from #2. So if a method automatically set a field to 0 you can easily overwrite the value for that field with 1.

It should be that difficult really, I don't have much of experience with DBTNG, but that's a hurdle for early next year :)

 
 

Drupal is a registered trademark of Dries Buytaert.