The test should be deivred from some kind of use case. The funny thing is that first you introduced your class, then talked about writing a test, which is backwards to TDD.The use case informs the test, which informs the code. I highly doubt your use case is the user of my API can set a property called PartQty to any integer and always get back the integer they set . If that were the real use case, you'd write a unit test that checks int.MaxValue and int.MinValue. However, these are rarely real-world values.A real-world use case might look like: the user of my API news up a Bib injecting an IFlugleBinder, sets the PartQty to 4 and then calls the Execute method. This calls the Bind method on the IFlugleBinder instance 4 times. If that was the use case, your test would look very different.Honestly it looks like Bib is just a DTO of some kind. In my experience, most DTO's are just an artifact of some higher level use case. If the DTO is returned as some result of a function call that your API provides, then you should really be returning an interface, and the DTO class itself should be private, in which case it's not necessary to test it explicitly (just test the properties of the actual result you get from the method call). Likewise, if it's an internal DTO that's never exposed, then don't make it public. If your user has to provide some bundle of values, then your API should be accepting an interface. Let the user define their own class that implements the interface, or provide an immutable one, like this:public class Bib : IBib{ public Bib(int partQty) { PartQty = partQty; } public int PartQty { get; private set; }}Then you can write a test that checks if your constructor works if you want to be pedantic, but it's not that important.
Follow
The test should be deivred from some kind of use case. The funny thing is that first you introduced your class, then talked about writing a test, which is backwards to TDD.The use case informs the test, which informs the code. I highly doubt your use case is the user of my API can set a property called PartQty to any integer and always get back the integer they set . If that were the real use case, you'd write a unit test that checks int.MaxValue and int.MinValue. However, these are rarely real-world values.A real-world use case might look like: the user of my API news up a Bib injecting an IFlugleBinder, sets the PartQty to 4 and then calls the Execute method. This calls the Bind method on the IFlugleBinder instance 4 times. If that was the use case, your test would look very different.Honestly it looks like Bib is just a DTO of some kind. In my experience, most DTO's are just an artifact of some higher level use case. If the DTO is returned as some result of a function call that your API provides, then you should really be returning an interface, and the DTO class itself should be private, in which case it's not necessary to test it explicitly (just test the properties of the actual result you get from the method call). Likewise, if it's an internal DTO that's never exposed, then don't make it public. If your user has to provide some bundle of values, then your API should be accepting an interface. Let the user define their own class that implements the interface, or provide an immutable one, like this:public class Bib : IBib{ public Bib(int partQty) { PartQty = partQty; } public int PartQty { get; private set; }}Then you can write a test that checks if your constructor works if you want to be pedantic, but it's not that important.
--Rosinha 21:11, 25 June 2013 (CEST)