TDD adding simple properties

Question

I am currently doing my first real project with TDD.

I have written tests, and implemented most of the logic for the application.

However, there are properties I know I need to have on the UI, however, there is really no way to write a useful test which will cause their creation.

For example, a description field. It's the ID that is really cared about in the logic of the application, but the actual description is just carried along from when it's populated and sent to the UI.

How would you go about writing a test that is worthwhile, since a new property is literally nothing more than.

public string foo { get;set; }

This seems to be a way to go about testing these, http://stackoverflow.com/a/910463/54746 — CaffGeek, May 16 '12 at 15:46

score 3 · Answer 1 · edited May 16 '12 at 15:15

3

In TDD unit test are not your only source of tests, you have to include Acceptances tests as well with a framework like Selenium in the case of Web development. To bullet proof your application even more, using a build automation upon each commit like Jenkins which you can combine with Apache Ant to run all your tests and different code analysis.

For more information you can look at this presentation. Even without the presenter talking, you can understand where he is going.

edited May 16 '12 at 15:15

gnat

21,442
29
112
288

answered May 16 '12 at 15:00

JF Dion

530
3
12

+1 for _not your only source of tests_ - although I was really tempted to downvote for referring to [old-fashioned Ant](http://programmers.stackexchange.com/a/120322/31260 "I'd rather be surprised seeing someone who prefers ant over maven") :) – gnat May 16 '12 at 15:18
@gnat: The PHP template for jenkins still relies on Apache Ant http://jenkins-php.org/ for build automation – JF Dion May 16 '12 at 15:27
But that still doesn't explain, with TDD, how I create the test that requires writing the code for the property. – CaffGeek May 16 '12 at 15:31
@Chad: You don't need to have a 100% code coverage to have valid TDD, if your core logic is tested and your interface behave as expected you have a pretty good chance that these properties are covered. If you still really want to test thoses, you could test that the output contains the description value. (still using web development as example) To achieve that you could mock the request that will return a predictable content and then check for specific parts by traversing the sections you want to test (do the content of div#user .description = expected value) – JF Dion May 16 '12 at 15:40
@Chad you (_developer_) don't do that, _testers_ do. What _you_ do is, 1) help testers arrange [coverage](http://en.wikipedia.org/wiki/Code_coverage "what's this?") monitoring and results merge for _all_ kinds of tests, your and their 2) analyze coverage data provided by testers in order to find gaps 3) if gaps are discovered in setters, propose _use cases_ that would cover it 4) track that testers added and run the proposed case 5) verify that gap has been gone. You, _developer_, do _not_ write tests for that - it's done the other way (and it's quite a fun way imNSho) – gnat May 17 '12 at 14:21
@gnat. I'm talking about TDD. Test First, Code Second. Without a test, there's no way to justify writing the line of code. – CaffGeek May 17 '12 at 15:21
@Chad sure, no problem - find out and pass to testers the use case _before_ writing the code. Test First, Code Second - here you go. – gnat May 17 '12 at 15:40
1

@gnat, that makes no sense. That's not TDD at all. – CaffGeek May 17 '12 at 16:07
@Chad agree this doesn't fit [formally](http://en.wikipedia.org/wiki/Test-driven_development "developer writes blah blah..."). However since you asked about _writing a test that is worthwhile_, this is the most reasonable way to go _worthwhile_ – gnat May 17 '12 at 16:20

score 2 · Answer 2 · answered May 16 '12 at 14:24

I wouldn't bother writing tests for something that doesn't have any logic in it. If your properties are really that simple, writing unit-tests for them is a bad idea. Those tests will be brittle, and will almost never catch any bugs. You're not really testing anything at all. I'm not sure how this advice works with pure TDD, but from a practical point of view, you should only write tests for things that involve logic.

However, it's possible to have more complicated properties that contain some logic. In this case, it might be good to write unit tests for them. For example, if a setter enforces some data valid data range (0 <= property value <= 100), then you can write tests that ensure that this works.

I understand when there is data validation, that it makes sense. I just don't get how I can write the code to create a property when I can't think of a valid test for it. — CaffGeek, May 16 '12 at 15:28
If you insist on writing a test for this, how about something like: obj.setValue(5); assert(5, obj.getValue()) — Oleksi, May 16 '12 at 15:36

score 1 · Answer 3 · answered May 16 '12 at 16:04

1

If you need a property, you have a feature that requires that property to be there. In the course of writing unit tests for that feature, you will reference that property and thus its existence will be validated by a unit test.

answered May 16 '12 at 16:04

Michael Brown

21,684
3
46
83

TDD adding simple properties

3 Answers3