tpendragon · December 5, 2014 23:16
diff --git a/irc_log.txt b/irc_log.txt
 13:53 terrellt: I'm starting to flex my opinions about how specs should be written and I'd like some input from anybody out there writing Capybara specs.
 13:53 terrellt: If somebody has time and an interest in the conversation, could you look at https://github.com/OregonDigital/oregondigital/pull/705 ?
 13:55 jcoyne: terrellt: view specs are much better than feature specs for particular cases like this.  Feature specs are great to make sure all the layers are connected together correctly
 13:56 terrellt: If this were two years ago I'd scoff at view specs at all. If it were a year ago I'd agree and write a Capybara test to make sure what I'm testing here holds true.
 13:57 terrellt: I'm starting to think enforcing the interface in my test does the last part.
 13:57 jcoyne: terrellt: I like to think of feature specs like the features you describe to your users.
 13:58 jcoyne: Like "You can upload a file, supply some metadata and then it shows up in the search"
 13:58 jcoyne: But not the particular edge cases of that feature
 15:04 terrellt: jcoyne: I've shown up! I'm starting to think your scenario is solved by a view spec with certain fields, a controller spec that initializes a service object, and a service object spec that determines that it can persist an item such that it's searchable.
 15:04 jcoyne: right.
 15:04 terrellt: Maybe that's not the right split, but it's close.
 15:05 jcoyne: but it's good to also have a feature spec that makes sure all the parts work together correctly, but only a minimal number of them.
 15:05 terrellt: -Is- it? At what point does a feature spec become duplication.
 15:06 terrellt: I've tested the interface and that the interface is used.
 15:08 terrellt: Again, please don't take this to be I think I have the answer, but this is feeling like a tipping point.
 15:08 jcoyne: terrellt: I'm not saying you *have* to have them
 15:08 terrellt: What is an optional test if not cruft?
 15:09 jcoyne: Terrellt: Do you have javascript?
 15:10 terrellt: Not in this interaction. If there's Javascript then that's a BIG part that would be missed, and either A) A JS-enabled feature spec or B) Maybe I need to think about JS unit tests.
 15:11 jcoyne: jsunit tests are hard with jquery.  Something like Angular would make that a lot better.
 15:11 terrellt: Yes, I suspect I'd just write the feature spec for JS interactions.
 15:11 terrellt: But I might feel dirty about it.
 15:12 terrellt: I think what's happened with the ease that Capybara specs gives me validity of my FEATURES is clouding TDD's ability to provide feedback on architecture.
 15:12 terrellt: is that it's clouding*
 15:14 jcoyne: Yes, Capybara is sort of like a self-destructive habit.
	13:53 terrellt: I'm starting to flex my opinions about how specs should be written and I'd like some input from anybody out there writing Capybara specs.
	13:53 terrellt: If somebody has time and an interest in the conversation, could you look at https://github.com/OregonDigital/oregondigital/pull/705 ?
	13:55 jcoyne: terrellt: view specs are much better than feature specs for particular cases like this. Feature specs are great to make sure all the layers are connected together correctly
	13:56 terrellt: If this were two years ago I'd scoff at view specs at all. If it were a year ago I'd agree and write a Capybara test to make sure what I'm testing here holds true.
	13:57 terrellt: I'm starting to think enforcing the interface in my test does the last part.
	13:57 jcoyne: terrellt: I like to think of feature specs like the features you describe to your users.
	13:58 jcoyne: Like "You can upload a file, supply some metadata and then it shows up in the search"
	13:58 jcoyne: But not the particular edge cases of that feature
	15:04 terrellt: jcoyne: I've shown up! I'm starting to think your scenario is solved by a view spec with certain fields, a controller spec that initializes a service object, and a service object spec that determines that it can persist an item such that it's searchable.
	15:04 jcoyne: right.
	15:04 terrellt: Maybe that's not the right split, but it's close.
	15:05 jcoyne: but it's good to also have a feature spec that makes sure all the parts work together correctly, but only a minimal number of them.
	15:05 terrellt: -Is- it? At what point does a feature spec become duplication.
	15:06 terrellt: I've tested the interface and that the interface is used.
	15:08 terrellt: Again, please don't take this to be I think I have the answer, but this is feeling like a tipping point.
	15:08 jcoyne: terrellt: I'm not saying you have to have them
	15:08 terrellt: What is an optional test if not cruft?
	15:09 jcoyne: Terrellt: Do you have javascript?
	15:10 terrellt: Not in this interaction. If there's Javascript then that's a BIG part that would be missed, and either A) A JS-enabled feature spec or B) Maybe I need to think about JS unit tests.
	15:11 jcoyne: jsunit tests are hard with jquery. Something like Angular would make that a lot better.
	15:11 terrellt: Yes, I suspect I'd just write the feature spec for JS interactions.
	15:11 terrellt: But I might feel dirty about it.
	15:12 terrellt: I think what's happened with the ease that Capybara specs gives me validity of my FEATURES is clouding TDD's ability to provide feedback on architecture.
	15:12 terrellt: is that it's clouding*
	15:14 jcoyne: Yes, Capybara is sort of like a self-destructive habit.