4

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; }
Improve this question
1

3 Answers 3

Reset to default
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.

Improve this answer
9
  • +1 for not your only source of tests - although I was really tempted to downvote for referring to old-fashioned Ant :)
    – gnat
    May 16, 2012 at 15:18
  • @gnat: The PHP template for jenkins still relies on Apache Ant jenkins-php.org for build automation
    – JF Dion
    May 16, 2012 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, 2012 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, 2012 at 15:40
  • 1
    @gnat, that makes no sense. That's not TDD at all.
    – CaffGeek
    May 17, 2012 at 16:07
2

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.

Improve this answer
2
  • 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, 2012 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, 2012 at 15:36
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.