Timeline for Should I validate API output?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 11, 2015 at 0:31 | comment | added | user2097245 | Validation will not guard against renames. All the validation does is check the values in the DTO. Any renames would propagate to the validation method, too. Renames should break the unit tests, anyway. The contents are what I was asked to validate. I thought the same thing: I should be testing the XML generation, not not validating at run-time that the content is correct after just being transformed twice. | |
| Apr 10, 2015 at 4:40 | comment | added | Rocklan | Having a DataMember attribute won't make it clear that any renaming will break the contract.. someone will not realise that. Even having a datamember name property won't help (someone will just rename that too). I considered the same thing but realised I was just duplicating stuff for the sake of reminding any possible future dev to not break it - which won't work. If you have a test, that'll help. The contents don't matter all that much, it's the structure that you need to worry about. If you need to test the contents, then unit test the function that generates the content not the final XML. | |
| Apr 10, 2015 at 3:58 | comment | added | user2097245 | I'm more concerned with the contents of the DTOs rather than the structure. In my case, the output format is determined by the DTO structure, and the DTOs are marked with DataContract and DataMember attributes. I hope that would make it clear that any renaming would be changing the contract. I had considered explicitly setting the DataMember Name properties to avoid the renaming issue entirely. | |
| Apr 10, 2015 at 1:16 | history | answered | Rocklan | CC BY-SA 3.0 |