{"__v":0,"_id":"56a6824e683cfb0d00dc586f","category":{"__v":9,"_id":"5696c1168560a60d00e2c1d6","pages":["5696c11aaa12bc0d0050332c","5696c11aaa12bc0d0050332d","5696c11a8400d52d00dd5631","5696c11a59a6692d003fad06","56a007d14583912300b5efcf","56a007d166c8420d00d7fc7c","56a6824e683cfb0d00dc586f","56b383fe3ccec63700a7ac1c","56b3a7de0e4c450d00699d22"],"project":"568fde81b700ce0d002f4b43","version":"56954a94fe18811700c9bfda","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-13T21:26:46.069Z","from_sync":false,"order":5,"slug":"references","title":"References"},"parentDoc":null,"project":"568fde81b700ce0d002f4b43","user":"568fffce769f210d0013258f","version":{"__v":6,"_id":"56954a94fe18811700c9bfda","project":"568fde81b700ce0d002f4b43","createdAt":"2016-01-12T18:48:52.007Z","releaseDate":"2016-01-12T18:48:52.007Z","categories":["56954a95fe18811700c9bfdb","56954a95fe18811700c9bfdc","56954a95fe18811700c9bfdd","56954a95fe18811700c9bfde","56954a95fe18811700c9bfdf","56954a95fe18811700c9bfe0","56954a95fe18811700c9bfe1","56954a95fe18811700c9bfe2","56954a95fe18811700c9bfe3","56954a95fe18811700c9bfe4","5695649fdcaf0d1700cb8721","5696c1168560a60d00e2c1d6","56a7a32e79395317007c1ad6","5898fc3eec49fb0f004c2663","589cc675ea37da23004e05e1"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"foo","version_clean":"0.0.0","version":"0.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-25T20:15:10.933Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"# Contents\n\n- :fa-angle-right: [Adding unncessary waits](#section-adding-unnecessary-waits)\n\n***\n\n# Adding unncessary waits\n\nIn Cypress, you almost **never** need to `cy.wait` for an arbitrary period of time. If you are finding yourself do this, there is likely a much better, simpler way.\n\nLet's imagine the following example:\n\n[block:code]\n{\n    \"codes\": [\n        {\n            \"code\": \"cy\\n  .request(\\\"http://localhost:8080/db/seed\\\")\\n  .wait(5000)     // <--- this is unnecessary\\n  .visit(\\\"http://localhost/8080\\\")\\n  .wait(5000)     // <--- this is unnecessary\\n  .server()\\n  .route(\\\"GET\\\", /users/, [{\\\"name\\\": \\\"Maggy\\\"}, {\\\"name\\\": \\\"Joan\\\"}])\\n  .get(\\\"#fetch\\\").click()\\n  .wait(4000)     // <--- this is unnecessary\\n  .get(\\\"table tr\\\").should(\\\"have.length\\\", 2)\\n\",\n            \"language\": \"javascript\"\n        }\n    ]\n}\n[/block]\n\nEach arbitrary wait is unnecessary in the example above.\n\n1. [`cy.request`](https://on.cypress.io/api/request) - waiting for this is unnecessary because this command will not resolve **until** it receives a response from your server. Adding the wait here only adds **5 seconds** after the `cy.request` has *already* resolved.\n2. [`cy.visit`](https://on.cypress.io/api/visit) - waiting for this is unnecessary because this command will resolve once the page fires its `load` event. By that time all of your assets have been loaded including `javascript`, `stylesheets`, and `html`.\n3. [`cy.get`](https://on.cypress.io/api/route) - waiting for the `cy.get` is unncessary because `cy.get` will automatically continue to retry until the `table tr` has a length of 2. Whenever commands have an assertion they will not resolve until their associated assertions pass. This enables you to simply describe the **state** of your application without having to worry about *when* it gets there. Alternatively a better solution to this problem is by waiting explictly for an aliased route.\n\nThe following is the least brittle way of writing the following:\n\n[block:code]\n{\n    \"codes\": [\n        {\n            \"code\": \"cy\\n  .request(\\\"http://localhost:8080/db/seed\\\")\\n  .visit(\\\"http://localhost/8080\\\")\\n  .server()\\n  .route(\\\"GET\\\", /users/, [{\\\"name\\\": \\\"Maggy\\\"}, {\\\"name\\\": \\\"Joan\\\"}]).as(\\\"getUsers\\\")\\n  .get(\\\"#fetch\\\").click()\\n  .wait(\\\":::at:::getUsers\\\")     // <--- wait explicitly for this route to finish\\n  .get(\\\"table tr\\\").should(\\\"have.length\\\", 2)\\n\",\n            \"language\": \"javascript\"\n        }\n    ]\n}\n[/block]\n\nBy waiting for the `getUsers` route, Cypress is smart enough to not only wait for a request to go out, but also for a response to come back in.","excerpt":"Patterns which you should avoid","slug":"anti-patterns","type":"basic","title":"Anti-patterns"}

Anti-patterns

Patterns which you should avoid

# Contents - :fa-angle-right: [Adding unncessary waits](#section-adding-unnecessary-waits) *** # Adding unncessary waits In Cypress, you almost **never** need to `cy.wait` for an arbitrary period of time. If you are finding yourself do this, there is likely a much better, simpler way. Let's imagine the following example: [block:code] { "codes": [ { "code": "cy\n .request(\"http://localhost:8080/db/seed\")\n .wait(5000) // <--- this is unnecessary\n .visit(\"http://localhost/8080\")\n .wait(5000) // <--- this is unnecessary\n .server()\n .route(\"GET\", /users/, [{\"name\": \"Maggy\"}, {\"name\": \"Joan\"}])\n .get(\"#fetch\").click()\n .wait(4000) // <--- this is unnecessary\n .get(\"table tr\").should(\"have.length\", 2)\n", "language": "javascript" } ] } [/block] Each arbitrary wait is unnecessary in the example above. 1. [`cy.request`](https://on.cypress.io/api/request) - waiting for this is unnecessary because this command will not resolve **until** it receives a response from your server. Adding the wait here only adds **5 seconds** after the `cy.request` has *already* resolved. 2. [`cy.visit`](https://on.cypress.io/api/visit) - waiting for this is unnecessary because this command will resolve once the page fires its `load` event. By that time all of your assets have been loaded including `javascript`, `stylesheets`, and `html`. 3. [`cy.get`](https://on.cypress.io/api/route) - waiting for the `cy.get` is unncessary because `cy.get` will automatically continue to retry until the `table tr` has a length of 2. Whenever commands have an assertion they will not resolve until their associated assertions pass. This enables you to simply describe the **state** of your application without having to worry about *when* it gets there. Alternatively a better solution to this problem is by waiting explictly for an aliased route. The following is the least brittle way of writing the following: [block:code] { "codes": [ { "code": "cy\n .request(\"http://localhost:8080/db/seed\")\n .visit(\"http://localhost/8080\")\n .server()\n .route(\"GET\", /users/, [{\"name\": \"Maggy\"}, {\"name\": \"Joan\"}]).as(\"getUsers\")\n .get(\"#fetch\").click()\n .wait(\"@getUsers\") // <--- wait explicitly for this route to finish\n .get(\"table tr\").should(\"have.length\", 2)\n", "language": "javascript" } ] } [/block] By waiting for the `getUsers` route, Cypress is smart enough to not only wait for a request to go out, but also for a response to come back in.