3 ms·

It's clear to me what my code needs to do, however there are a myriad of environmental factors that can fuck up what my simple code needs to do. For instance,

by douche 12y ago

It's clear to me what my code needs to do, however there are a myriad of environmental factors that can fuck up what my simple code needs to do. For instance, a common thing that I need to do is to look up one Active Directory property based on another. Depending on the environment, I may have access to that property using the logged-in user's credentials, or I may need to use a special service account set of credentials in my application, defined in a database or an app/web.config. At some point, an over-zealous administrator can disable the rights for the account that my application is using inside a client organization. Then I end up on the phone for an hour or more, figuring out why an account that used to work no longer does, and getting my clients to raise a change request with the admins that broke our application in the first place to put things back.

coldtea 12y ago
>It's clear to me what my code needs to do, however there are a myriad of environmental factors that can fuck up what my simple code needs to do. For instance, a common thing that I need to do is to look up one Active Directory property based on another. Depending on the environment, I may have access to that property using the logged-in user's credentials, or I may need to use a special service account set of credentials in my application, defined in a database or an app/web.config. Some stuff you test in unit tests, other you do functional testing for. What you describe is probably higher level than unit tests. >At some point, an over-zealous administrator can disable the rights for the account that my application is using inside a client organization. Then I end up on the phone for an hour or more, figuring out why an account that used to work no longer does, and getting my clients to raise a change request with the admins that broke our application in the first place to put things back. So? That's orthogonal to your app. You test that your app works if the rights are working OK, and you test what it shows to the user if the rights are not OK. Other than that, obviously you cannot ensure it works without things it needs to have, nor do you need to test each and every externally dependent failure mode (e.g. user wiped out his hard drive).
BurningFrog 12y ago
If you actually know all these myriad environmental factors, writing tests for them is no harder than for anything else. It could be a lot of work, of course, but that just reflects that you're building a complex system. Test 1: Look up AD prop with user credentials Test 2: Look up AD prop when user credentials don't work You'd almost certainly want to mock out the environment. Don't use the actual services.
timv 12y ago
These two comments (below) seem to be in opposition to one another. It's clear to me what my code needs to do (Above) How do I even know what correct outputs to code interacting with those components would be? (From your original comment) If you know all the possible environmental factors that you need to deal with, then you can write up front tests for them (whether that is economical or not, is a different question). However, if the complete set of environmental factors is unknown (though potentially discoverable) then you have a requirements problem, not a code problem. TDD can't solve that problem (although it might help make it obvious that the problem exists). TDD is based on the assumption that it is possible to know when your code "works", and requires you to define that criteria up front. But any development process you follow is must have some way of answering the "am I done yet?" question, or you'd never ship anything. Perhaps your concern is that TDD doesn't help solve the "I don't have a complete set of requirements" problem. If so, then that's true, but it never claims to. If you don't have the requirements yet, then TDD says you're not ready to write code, and some other process has to be followed in order to produce requirements. It is possible to do TDD if you only have some (but not all) requirements - but you can only write code for the requirements you do have.

by douche 12y ago

coldtea 12y ago

>It's clear to me what my code needs to do, however there are a myriad of environmental factors that can fuck up what my simple code needs to do. For instance, a common thing that I need to do is to look up one Active Directory property based on another. Depending on the environment, I may have access to that property using the logged-in user's credentials, or I may need to use a special service account set of credentials in my application, defined in a database or an app/web.config. Some stuff you test in unit tests, other you do functional testing for. What you describe is probably higher level than unit tests. >At some point, an over-zealous administrator can disable the rights for the account that my application is using inside a client organization. Then I end up on the phone for an hour or more, figuring out why an account that used to work no longer does, and getting my clients to raise a change request with the admins that broke our application in the first place to put things back. So? That's orthogonal to your app. You test that your app works if the rights are working OK, and you test what it shows to the user if the rights are not OK. Other than that, obviously you cannot ensure it works without things it needs to have, nor do you need to test each and every externally dependent failure mode (e.g. user wiped out his hard drive).

BurningFrog 12y ago

If you actually know all these myriad environmental factors, writing tests for them is no harder than for anything else. It could be a lot of work, of course, but that just reflects that you're building a complex system. Test 1: Look up AD prop with user credentials Test 2: Look up AD prop when user credentials don't work You'd almost certainly want to mock out the environment. Don't use the actual services.

timv 12y ago

These two comments (below) seem to be in opposition to one another. It's clear to me what my code needs to do (Above) How do I even know what correct outputs to code interacting with those components would be? (From your original comment) If you know all the possible environmental factors that you need to deal with, then you can write up front tests for them (whether that is economical or not, is a different question). However, if the complete set of environmental factors is unknown (though potentially discoverable) then you have a requirements problem, not a code problem. TDD can't solve that problem (although it might help make it obvious that the problem exists). TDD is based on the assumption that it is possible to know when your code "works", and requires you to define that criteria up front. But any development process you follow is must have some way of answering the "am I done yet?" question, or you'd never ship anything. Perhaps your concern is that TDD doesn't help solve the "I don't have a complete set of requirements" problem. If so, then that's true, but it never claims to. If you don't have the requirements yet, then TDD says you're not ready to write code, and some other process has to be followed in order to produce requirements. It is possible to do TDD if you only have some (but not all) requirements - but you can only write code for the requirements you do have.