Our team occasionally leverages TDD, and we certainly write unit tests for all our code (even if not as TDD). However, one area we continue to struggle with is how TDD applies to UI-centric code.
It's easy enough to write a test for something functional or algorithmic (lots of inputs and outputs to check). It's not necessarily straightforward to write a test for UI code, before the code exists.
For example, UI unit tests often test the state of visual widgets to see if they were updated properly by some data. However, you may not have decided on the type/name of each widget before writing the code, and so the test can't be meaningfully constructed.
I'd be interested to know if you are applying TDD to UI-centric code, and if so what your recommendations are.
On TDD for UI code. We've had a great amount of success doing it. Our biggest gain was from separating out the mechanics of the testing from the testing itself. We did this by creating a simple scripting language, which allows us to specify tests like:
Setup dataset1 Load Homepage Set element name to foo Click go Check message is "You typed foo"
It was a significant investment, but has paid dividends. We're testing web based apps, the script gets translated into PHP which drives a browser with COM and uses SimpleTest to make assertions. The good thing is that we don't have to worry about this complexity when writing the tests.
Another reason to make sure the test fails first is so that you're sure it's testing the right code. If you write the code to add a feature first and then the test, a passing test doesn't prove the new feature is being exercised.
I've never read an article on TDD that actually made me want to try it. It always seemed like so much trouble for very little gain. The way you explained the advantages makes it sound like fun! I just might try it. Thanks!
I have recently started looking at TDD and one of the challenges that I faced is testing private methods. I am actually curious how do you guys go about this?
I came up with a solution that leverages aspect oriented programming, but I am not sure what would everyone else think about it.
Khaled, we use Reflection to test private methods in Java.
However, it's always a judgment call of *which* private methods should be unit tested, since many are covered thoroughly by testing public methods.
Here are some general guidelines:
* Does the private method include one or more corner cases that would be challenging to test via a public method that routes through this private method? If so, maybe unit test the private method.
* Does the private method encapsulate an algorithm with many input/output possibilities, which would be challenging to validate without direct inspection of its return values? If so, you might unit test the private method so you can easily exhaust dozens or hundreds of inputs/outputs.
* Does the private method only get called under exceptional circumstances by public methods, that would be difficult to reproduce in a unit test? If so, you might just unit test the private method.
I know there's a bit of a holy war around whether or not to unit test private methods (and there are certainly architectural approaches you can take from the outset, to avoid the three points I listed above), but I think it's reasonable in some cases.
From a technical perspective, check out Reflection in Java, or see if your language of choice has something similar.
Our team occasionally leverages TDD, and we certainly write unit tests for all our code (even if not as TDD). However, one area we continue to struggle with is how TDD applies to UI-centric code.
ReplyDeleteIt's easy enough to write a test for something functional or algorithmic (lots of inputs and outputs to check). It's not necessarily straightforward to write a test for UI code, before the code exists.
For example, UI unit tests often test the state of visual widgets to see if they were updated properly by some data. However, you may not have decided on the type/name of each widget before writing the code, and so the test can't be meaningfully constructed.
I'd be interested to know if you are applying TDD to UI-centric code, and if so what your recommendations are.
I found a bug on the first day of release of Google Chrome.
ReplyDeletewhile entering :% in address bar it crashed. So strange.
Really a BIG ad for tdd, but I love it!
ReplyDeleteThanks for your explanation.
great question vvagell...anyone have any thoughts on TDD on UI code?
ReplyDeleteOn TDD for UI code. We've had a great amount of success doing it. Our biggest gain was from separating out the mechanics of the testing from the testing itself. We did this by creating a simple scripting language, which allows us to specify tests like:
ReplyDeleteSetup dataset1
Load Homepage
Set element name to foo
Click go
Check message is "You typed foo"
It was a significant investment, but has paid dividends. We're testing web based apps, the script gets translated into PHP which drives a browser with COM and uses SimpleTest to make assertions. The good thing is that we don't have to worry about this complexity when writing the tests.
Another reason to make sure the test fails first is so that you're sure it's testing the right code. If you write the code to add a feature first and then the test, a passing test doesn't prove the new feature is being exercised.
ReplyDeleteI've never read an article on TDD that actually made me want to try it. It always seemed like so much trouble for very little gain. The way you explained the advantages makes it sound like fun! I just might try it. Thanks!
ReplyDeleteI have recently started looking at TDD and one of the challenges that I faced is testing private methods. I am actually curious how do you guys go about this?
ReplyDeleteI came up with a solution that leverages aspect oriented programming, but I am not sure what would everyone else think about it.
http://www.khussein.com/wordpress/?p=38
Thanks,
Khaled
Khaled, we use Reflection to test private methods in Java.
ReplyDeleteHowever, it's always a judgment call of *which* private methods should be unit tested, since many are covered thoroughly by testing public methods.
Here are some general guidelines:
* Does the private method include one or more corner cases that would be challenging to test via a public method that routes through this private method? If so, maybe unit test the private method.
* Does the private method encapsulate an algorithm with many input/output possibilities, which would be challenging to validate without direct inspection of its return values? If so, you might unit test the private method so you can easily exhaust dozens or hundreds of inputs/outputs.
* Does the private method only get called under exceptional circumstances by public methods, that would be difficult to reproduce in a unit test? If so, you might just unit test the private method.
I know there's a bit of a holy war around whether or not to unit test private methods (and there are certainly architectural approaches you can take from the outset, to avoid the three points I listed above), but I think it's reasonable in some cases.
From a technical perspective, check out Reflection in Java, or see if your language of choice has something similar.
Hello @ all! :-)
ReplyDeleteTo the subject: "TDD with UI-centric code":
You could try out this approach: Presenter first
The thing with private Methods: Is private method an antipattern?!
I hope, that I could help a little. :-)
best regards, Christian