search

BuoySoftware / guides

Documentation for Buoy Software
2 stars 0 forks source link

Prefer one expectation per `it` #85

Closed acostanzo closed 3 months ago

acostanzo commented 3 months ago

This PR came from a conversation started here: https://github.com/BuoySoftware/Wharf/pull/3865#discussion_r1682948116

joshuaswilcox commented 3 months ago

I think this will significantly slow tests if, for example, you have to build all your state up multiple time just to test the postitve and negative of a method, for example, a filter that should only have the "active" object you want to ensure the result has only active while also making sure the result does not have any inactive.

joshuaswilcox commented 3 months ago

I dont see how it would sensible to test only one thing in a feature tests. We use a pattern of:

Go to a page Expect page to have content Do an action Expect page to not have content

as an example, to breaking that into multiple test would not make it very useful.

acostanzo commented 3 months ago

I agree with @joshuaswilcox on feature specs. In practice with those, we usually take a step, check for something, take a further step check for another thing, etc. This proposal is more intended for non feature specs.

chadellison commented 3 months ago

Moving this over here from https://github.com/BuoySoftware/Wharf/pull/3865#discussion_r1683034296 I think it makes sense to have one expectation per unit test and multiple expectations for integration / acceptance tests, with the idea that the unit tests should stub expensive state setup, like db transactions (though I know this is not always possible). I think the benefit to having one expectation is being able to see what failed more quickly. I can imagine exceptions to this as well / times where it may make sense to have multiple. I'm curious about others' thoughts though.