3 ms·

It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an accepta

It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I have a rule on my teams that integration tests are allowed to know about some internals and use them. Acceptance test steps are not allowed to know about anything that isn't an accepted part of the domain vocabulary and the user interface of the SUT. There's an advantage to this as well, if you practice something that approximates DDD: you can use the same test to hit your domain library as your user interface. The step implementations are different, obviously, but the gherkin test is the same. Also, I definitely agree with those who have stated elsewhere that customer collaboration is a red herring. I've guided customer discussions with cukes before (e.g. talking about edge cases and aspects they haven't thought about), but never has customers writing cukes been a good experience.

dragonwriter 13y ago
> It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I agree that there is a big difference (I'd describe it differently because I don't think of ITs as being about code, I think of UT as being about code, ITs as being about architecture, and ATs as being about domain concepts, but that's, arguably, quibbling); I just think its a difference that often manifests more in terms of the organization of the who-does-what-and-how outside of the tool but which, between ITs and ATs, doesn't necessarily make a huge difference in desirable tool features. (Particularly, I think than non-code language for tests can have value for ITs, though the style of the language and its audience is different than for ATs.)

dragonwriter 13y ago

> It may not be the worst, but i don't think its the best either. There's a world of difference in thought and language between an integration test and an acceptance test—IT's are about code. AT's are about concepts. I agree that there is a big difference (I'd describe it differently because I don't think of ITs as being about code, I think of UT as being about code, ITs as being about architecture, and ATs as being about domain concepts, but that's, arguably, quibbling); I just think its a difference that often manifests more in terms of the organization of the who-does-what-and-how outside of the tool but which, between ITs and ATs, doesn't necessarily make a huge difference in desirable tool features. (Particularly, I think than non-code language for tests can have value for ITs, though the style of the language and its audience is different than for ATs.)