views:

103

answers:

4

I would like to get some feedback on what is one of my first PHPUnit test cases.

The subject of the tests is a simple configuration class in a PHP app. It is used to create, store and retrieve configuration settings.

The settings are stored in an array within the class. Each setting has the following properties:

  • key (for example frontend:menu:bgcolor)

  • type (one of string, int, hexcolor, boolean)

  • value (mixed)

  • read only (boolean)

Every setting has to be created first. On creation, each setting is assigned a type, the read only flag (defaults to false), and a default value.

Class methods:

public function create($key, $value, $type = "string", $read_only = false) 
public function set($key, $value)   
public function get($key)  

The tests I am running:

(ok) and (fail) are the expected results of the test.

  • Create a setting named test with type string with an initial value xyz (ok)

  • Load the setting test and expect return value xyz (ok)

  • Set the setting test to abc (ok)

  • Load the setting test and expect return value abc (ok)

  • Load the setting töst (fail, key doesn't exist)

  • Create a setting named test_read_only with type string, an initial value Mary had a little lamb and the read-only flag set to true (ok)

  • Set the setting named test_read_only to Peter had a big lamb (fail, key is read only)

  • Load the setting named test_read_only and expect return value Mary had a little lamb (ok)

  • Create a setting named test_integer with type int, an initial value 5 and the read-only flag set to true (ok)

  • Create a setting named test_integer_second with type int, and an initial value 5.23049505906 (fail, initial value has wrong type)

  • Create a setting named test_weird with type sdasfäödsf#ädfsaö (fail, type not found)

  • Set the setting named test_weird to Peter had a little lamb (fail, key not defined)

Questions:

  • Does this test case make sense to you?
  • Would you consider this a complete test case?
  • What would you do differently, or in addition?

Update: Suggestions that have come up so far that I will implement:

  • String length checks
  • Tests involving the remaining data types boolean and hexcolor
  • Key naming tests are not necessary right now but will be in the future.
+2  A: 

The test cases as they are make sense, I would not consider them complete because you do not have any test cases for hexcolor or boolean values. Also, you may want to put some kind of limit on the length of the string values.

David
Nice, and with the string values limited we'll need some boundary test cases.
karim79
Very nice, cheers. I will complete the data type checks. Checking for string lengths and creating edge cases is a great idea.
Pekka
Also length limit on size of keys assuming the keys are strings.
David
+1  A: 

your test cover pretty much all that can be done, I think it's fairly good. unit test have not to be exhaustive (it's rarely possible)

I would only add something like this:

  • Set the setting test_integer to "abc" (fail, wrong type)

and maybe some tests for hexcolor and boolean type validation

mathroc
+2  A: 

I would add test for the missing types (boolean and hexcolor), with valid and not valid values).

I dont' know if you have some limitation in the naming convention of the keys, for example there are valid and not valid names you can assign to a key?

Another test you should absolutely add, to me: What happen if you create a key two times? With different types?

By the way you are doing well, to me

Eineki
Thank you! There is no key naming convention yet, but good point. I will definitely add tests for the remaining types. The behaviour on duplicate keys is defined very leniently in this class (it's allowed to overwrite) but will get a test either way.
Pekka
A: 

I would add tests for changing the type of an existing key. Also, for existing non-readonly key, change to readonly, and do it both with and without changing type.

Also, does your int type have a range? php can vary by platform. float can look like int.

chris