{"push_id":905674833,"size":1,"distinct_size":1,"ref":"refs/heads/refactor-feature-tests","head":"8df0c6e50a29635770e4a8c1562a33cab73d2b76","before":"d0cf4a4122a275b06470821f78bd2d5a18d545fb","commits":[{"sha":"8df0c6e50a29635770e4a8c1562a33cab73d2b76","author":{"email":"be8758dc4a66004612e74b567a662d4f1fbf4c2e@gmail.com","name":"Tijmen Brommet"},"message":"Rewrite core feature specs\n\nThe feature specs describe the functionality of this application. Over\nthe last year this app has gotten more responsibilities, growing the\nthese tests.\n\nIt has some problems:\n\n- Some are really large (~ 350 lines). It's hard to quickly scan which\nfunctionality is being tested.\n- They are hard to follow. Some of the tests have Cucumber-like\ncomments (When I make a change to the mainstream browse page), but\nother don't.\n- Lots of duplication in boilerplate code (create a record, navigate to\nthis page)\n- Duplicated tests. Many specs test a slightly different code branch,\nor test the same functionality twice.\n\nhese problems make the test suite hard to work with. A small change can\nbreak many tests at once, and it is hard to figure out why they are\nfailing. It is then challenging to figure out if the tests or the code\nshould change, resulting in shaky tests.\n\nThis PR rewrites the core feature specs for this app. It splits up the\nfunctionality into features and scenarios, using methods to implement\nthe different steps. By combining examples (use the same scenario for\ncreating and editing a record) we reduce of code necessary.\n\nThis is a technique also used in content-tagger and explained in this\nblog post:\n\nhttps://about.futurelearn.com/blog/how-we-write-readable-feature-tests-w\nith-rspec/","distinct":true,"url":"https://api.github.com/repos/alphagov/collections-publisher/commits/8df0c6e50a29635770e4a8c1562a33cab73d2b76"}]}