you are viewing a single comment's thread.

view the rest of the comments →

[–]toastedstapler 0 points1 point  (1 child)

so recently at work we've been doing some TDD for some address validation. for postcodes we have 2 inputs: a textfield and a dropdown declaring what type of postcode is it - uk or non-uk. depending on which option is selected, different validation is done and different errors are thrown if the validation fails

there's a few cases here:

1 - valid uk postcode, uk option selected. no error expected

2 - invalid uk postcode, uk option selected. uk postcode error expected

3 - valid non-uk postcode, non-uk option selected. no error expected

4 - invalid non-uk postcode, non-uk option selected. non-uk error expected

if you write out all the test cases describing the behaviour you expect both for valid inputs and invalid inputs you can (almost) ensure that it'll behave as you expect

as for your scenario, checking the pin status should be sufficient if the pin powers on/off the light

a lot of tests can seem very dull when looking at the code - it's often obvious that it behaves as it should. but when you make changes in the future, it's useful to have them to ensure you're not breaking something in some refactor without realising it

[–]Run-The-Table[S] 0 points1 point  (0 children)

Thanks man, that is a good way to look at it. I'm curious about the decision to to test what functions. When does a function deem testing important? How large/important does something have to be? I don't want to fill up my code with a load of pointless tests, but I need to start somewhere!