{"id":19841302,"url":"https://github.com/codelenny/ava-test-style","last_synced_at":"2026-03-02T23:33:15.084Z","repository":{"id":90327238,"uuid":"98205331","full_name":"CodeLenny/ava-test-style","owner":"CodeLenny","description":":book: AVA Test Style Guide","archived":false,"fork":false,"pushed_at":"2017-08-02T15:56:34.000Z","size":21,"stargazers_count":0,"open_issues_count":3,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-01-11T11:39:31.480Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CodeLenny.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-07-24T15:22:57.000Z","updated_at":"2017-07-24T18:09:40.000Z","dependencies_parsed_at":"2023-05-12T14:31:06.080Z","dependency_job_id":null,"html_url":"https://github.com/CodeLenny/ava-test-style","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodeLenny%2Fava-test-style","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodeLenny%2Fava-test-style/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodeLenny%2Fava-test-style/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CodeLenny%2Fava-test-style/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CodeLenny","download_url":"https://codeload.github.com/CodeLenny/ava-test-style/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241210691,"owners_count":19927816,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-12T12:29:57.320Z","updated_at":"2026-03-02T23:33:10.041Z","avatar_url":"https://github.com/CodeLenny.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"= Ryan's AVA Testing Organization Style\nRyan Leonard\n:ava: AVA\n:ava-link: https://github.com/avajs/ava\n:aval: link:{ava-link}[{ava}]\n:ava-assertions: link:https://github.com/avajs/ava#assertions[assertions]\n:ava-macros: test macros\n:ava-macrosl: link:https://github.com/avajs/ava#test-macros[{ava-macros}]\n:ava-plan: assertion planning\n:ava-planl: link:https://github.com/avajs/ava#assertion-planning[{ava-plan}]\n:mocha: Mocha\n:mochal: link:https://mochajs.org/[{mocha}]\n:chai: Chai\n:chail: link:http://chaijs.com/[{chai}]\n:node: Node.js\n:jsverify: JSVerify\n:jsverifyl: link:https://github.com/jsverify/jsverify[{jsverify}]\n:express: Express\n:expressl: link:http://expressjs.com/[{express}]\n:seleniumdrive: Selenium WebDriver\n:seleniumdrivel: link:http://www.seleniumhq.org/projects/webdriver/[{seleniumdrive}]\n:webdriver: WebDriverIO\n:webdriverl: link:http://webdriver.io/[{webdriver}]\n:babel: Babel\n:babell: link:https://babeljs.io/[{babel}]\n:supertest: SuperTest\n:supertestl: link:https://github.com/visionmedia/supertest[{supertest}]\n:status-code: HTTP status code\n:status-codel: link:https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html[{status-code}]\n:guide-link-title: Ryan's AVA Test Style\n:guide-link: https://github.com/CodeLenny/ava-test-style\n:guide-badge: https://img.shields.io/badge/AVA%20Test%20Style-@CodeLenny-blue.svg\n:do: image:https://img.shields.io/badge/-_DO_-brightgreen.svg[]\n:dotitle: DO:\n:dont: image:https://img.shields.io/badge/-DON'T-red.svg[]\n:donttitle: DON'T:\n:sectanchors:\n:sectlinks:\n:toc: preamble\n\n{aval} is a powerful testing platform that I've been using in most of my repositories instead of {mochal}.\nAfter trying out {ava} in many repositories, I've started to settle into a standard style that works well for creating\nclean, understandable, and simple testing files.\n\nThis document attempts to record my current style for writing {ava} tests.\nSome of my style is intuitive to {ava},\nlike using the built-in {ava-assertions} instead of external assertion libraries like {chail},\nbut other stylistic decisions are my own.\n\nThis guide is intended to serve as a reference for libraries that follow my style choices.\nIf you have differing style choices to mine, feel free to fork this style guide and tweak to your liking.\nYou can also submit issues or pull requests and discuss pros and cons to different choices, and I may tweak my style if\nconvinced that another way is better.\n\n.Embedable Badge image:{guide-badge}[]\n[source,md,subs=\"attributes\"]\n----\n[![AVA Test Style Guide]({guide-badge})]({guide-link})\n----\n\n.Text Reference\n[source,md,subs=\"attributes\"]\n----\nThis module is tested using [{ava}]({ava-link}).\nTests should conform to [{guide-link-title}]({guide-link}).\n----\n\n== Highlights\n\n- Tests are code, and should conform to lint rules.\n- The file-system reflects the organization of tests, and follows a \u003c\u003cFile-System Structure,standard pattern\u003e\u003e.\n- Unit tests are separated from integration tests.\n- Tests are designed for other humans.\n  Describe tests from the point of view of a user, without referencing implementation details.\n- Use property-based testing (such as {jsverifyl}) to find edge-cases and write concise tests.\n- Put all setup in `before`/`beforeEach` statements.\n- Duplicating documentation should be avoided at all costs.\n- Use built-in test organization messages over inline comments or `README` descriptions when possible.\n\n== Top-Level Test Organization\n\nTests are categorized by scope, ranging from small unit tests to larger integration tests.\nThis guide attempts to provide clear distinctions between unit and integration tests, and has named a few other test\ncategories.\n\nunit tests::\nIndependently testing a method, mocking all external dependencies.\nHTTP unit test::\nSimple usage or edge case testing of an HTTP method.\ninterface integration test::\nTesting a method against a single instance of an external dependency.\nAll other resources should be mocked.\nintegration test::\nA full-scale test involving almost no mocked components, that tests an entire flow from the user's perspective.\nRun with AVA in parallel to unit tests, before packaging.\npackage integration test::\nIf the application is packaged (such as a webserver packaged in a Docker image),\npackage integration tests run on the fully packaged build\n(such as using a Chrome instance to connect to the webserver running in Docker).\n\nThe test groups listed above are ordered from least to most expensive to run - starting a Docker image to test a smaller\ncomponent takes a lot longer than just running a short unit test with all external resources mocked.\n\nTherefore, unit tests should be used for most purposes.\nUnit tests should cover the basic usage of the method (give correct input, get correct response)\nand cover how the method handles edge cases (given invalid input, asked for non-existent resource, etc.).\n\nUnit tests should be validating the documented signature - expected parameters, calling other methods with the proper\nsignature, and returning the expected result.\n\nAll tests beyond unit tests should be minimal flows through the application.\n\nFor interface integration tests, when one class (`CallingClass`) calls another (`CalledClass`),\nwe've already checked that `CallingClass` calls `CalledClass` with the documented parameters,\nand separately tested that `CalledClass` returns the correct input when given the correct parameters.\n\nTherefore, the interface integration test is only testing that the two classes are in sync with each other, and don't\nhave any mistakes with basic usage.\n\nIntegration tests also test that already-tested components are wired together correctly, from a user's point of view.\nIntegration tests treat the entire application as a black box, and merely test input at one end compared to output at\nthe other.\n\nPackage integration tests should be even more minimal, just ensuring that the packaged application does start without\nany errors (such as missing dependencies or differences between the testing and packaged environments),\nand continues working with one or two basic flows through the application.\n\n[%hardbreaks]\n{do} Carefully organize testing files.\n{do} Focus on unit tests.\n{dont} Duplicate tests.\n\n=== File-System Structure\n\nMost of this documentation will assume a monolithic repository structure that includes several libraries packaged as NPM\npackages.\n\nWe'll use an webserver that deals with users and projects.\n\n----\nrepo/\n  package.json\n  web-server/\n    package.json\n    Dockerfile\n    Server.js\n    test/\n    package-test/\n  users/\n    auth/\n      AuthenticationMethod.js\n      PasswordAuthentication.js\n    package.json\n    Users.js\n    User.js\n    test/\n  projects/\n    package.json\n    Projects.js\n    Project.js\n    test/\n----\n\n`users`, and `projects` are each NPM libraries that are installed in `web-server`.\n\n`web-server/Server.js` will setup an {expressl} webserver\nwith routes that use `Users` and `Projects` to store and retrieve data for clients.\n\n`web-server` has a `package-test/` directory that contains tests that will run in browsers\n(such as through {seleniumdrivel} or {webdriverl}) against `Server` running in a Docker instance.\n\nAll other tests will be located in the `test/` directory for each module.\n\n=== Unit Test Organization\n\nUnit tests should be stored in `\u003cmodule\u003e/test/\u003cclass\u003e/\u003cmethod\u003e/\u003cscenario\u003e.js`.\n\nFor instance, tests that confirm `Users.getByID()` fetches users would be located in\n`users/test/Users/getByID/fetches-users.js`.\n\nIf classes have unique names, collapse directories when testing.\nFor instance, tests for `users/auth/AuthenticationMethod.js` can be located in `users/test/AuthenticationMethod/...`.\n\nIf classes do not have unique names, you can use directories inside `test/` to keep tests seperate.\nFor instance, the above tests could also be located inside `users/test/auth/AuthenticationMethod/...`.\n\nTry to collapse directories as much as possible.\nOnly use sub-directories in `test` if collapsing directories severely impacts understanding the test organization.\n\n=== HTTP Unit Tests Organization\n\nHTTP unit tests are an interesting mix - they should be isolated to a single \"method\", but you may need to access a\nlarger section of code to get the HTTP routing logic.\n\nIn general, HTTP routing logic should be basic wrappers around other functions.\nFor user registration, the logic might look like:\n\n[source,js]\n----\nconst Users = require(\"users/Users\");\nconst express = require(\"express\");\nconst bodyParser = require(\"body-parser\");\n\nclass Server {\n  constructor() {\n    this.app = express();\n    this.app.post(\"/register\", bodyParser.json(), (req, res) =\u003e {\n      const { email, password } = req.body;\n      Users\n        .register(email, password)\n        .then(user =\u003e {\n          req.redirect(\"/login\");\n        })\n        .catch(err =\u003e {\n          res.status(500);\n          res.send(\"Internal Error\");\n        });\n    });\n  }\n}\n----\n\nFor this example, `Users.register()` should be already unit tested, so the HTTP logic just needs to attempt to submit a\nform, and ensure that `Users.register()` is called with the correct information.\n\nHTTP unit tests should be located in `\u003cmodule\u003e/test/http/\u003curl\u003e/\u003chttp method\u003e/\u003cassertion\u003e.js`.\n\nThe test referenced above should be located in `server/test/http/register/POST/pass-to-Users-reigster.js`.\n\n=== Interface Integration Test Organization\n\nInterface integration tests are very similar to unit tests, and are stored almost identically.\nHowever, you should note what other modules are being used in the test.\n\nLet's test `Project#getOwner()`, which calls `Users.getByID()`, which in turn accesses the database.\n\nA unit test might be `projects/test/Project/getOwner/returns-user.js` should be run with `Users.getByID` mocked,\nand confirm that `Users.getByID()` is called with the ID of the project's owner, and correctly returns the user that\n`Users.getByID()` returns.\n\nFor interface tests, we will be testing that `Users.getByID` and `Project#getOwner` are correctly talking to each other.\n`projects/test/Project/getOwner/relays-Users-getByID.js` would use un-mocked `Users` and `Project` method, but should\nmock the contents of the database.\n\n=== Integration Test Organization\n\nIntegration tests should test user flow through the application, with minimal mocking.\n\nIn general, integration tests should be located in `\u003cmodule\u003e/test/integration/\u003cscenario\u003e/\u003cassertion\u003e.js`.\n\nFor instance, a test confirming users can log in after registering would be located in\n`users/test/integration/user-register-and-login/password-authentication.js`.\n\nIn general, integration tests should be confirming that the module works as a whole,\nso integration tests can be lumped together.\n\nHowever, integration tests that are isolated to a minor class that doesn't represent the rest of the module could be\nlocated inside the test directory for that class - such as `users/test/AuthenticationMethod/integration/...`.\n\n== What to Test\n\n=== Unit Test Contents\n\nUnit tests should be written for each method and function in the repository.\n\nInclude one test showing the basic usage:\n\n.`users/test/Users/getByID/fetches-users.js`\n[source,js]\n----\nconst id = \"dummy-user\";\nconst name = \"A Fake User\";\n// (pre-load database in `before()` hook)\n\ntest(\"finds user\", t =\u003e {\n  return Users\n    .getByID(id)\n    .then(user =\u003e {\n      t.is(user.name, name);\n    });\n});\n----\n\nNext, include tests for missed branches, such as error handling,\nadding additional tests for common uses that hit other branches.\nIt might help to examine line/branch/statement coverage reports.\n\nAlong with testing error cases, test that input validation correctly identifies improper input.\n\nFinally, test any easily identifiable edge cases.\nLook for bizarre input that should actually pass successfully, such as validating empty passwords,\nas well as documenting any errors that might be thrown, such as validating the password for a missing user.\n\nWhen responding to bug reports, normally new edge cases will be added as unit tests.\n\n[%hardbreaks]\n{do} Cover common cases, such as omitting optional arguments\n{dont} Test mis-use of functions, like omitting required arguments or providing arguments in the wrong order.\n\n=== HTTP Unit Test Contents\n\nFor HTTP routes that wrap unit-tested methods, testing can often be heavily mocked.\n\nGenerally, you should write one test that calls the underlying method,\nand checks that the output is correctly returned.\n\nThen evaluate any other branches.\nDoes the method respond with a {status-codel} and a custom body if an error is thrown in the test?\n\nSee any HTTP API documentation for the current module to see if there are other edge cases.\n\nTry to mock all resources under the wrapped method.  For some tests, you may even be able to mock the method completely,\nand only test the HTTP wrapper.\n\n[%hardbreaks]\n{do} Test HTTP parsing edge cases.\n{dont} Test edge-cases already covered by the wrapped method.\n\n=== Integration Interface Test Contents\n\nWhen testing the interface between two modules, start with a basic usage that uses both modules.\n\n[source,js]\n----\nconst name = \"my-sample-name\";\n\ntest.beforeEach(\"start server\", t =\u003e {\n  t.context.server = new Server();\n});\n\ntest.beforeEach(\"start client\", t =\u003e {\n  t.context.client = new Client();\n});\n\ntest(\"client can login after registration\", t =\u003e {\n  const { client } = t.context;\n  return client\n    .register({ name })\n    .then(() =\u003e client.login())\n    .then(user =\u003e {\n      t.is(user.name, name);\n    });\n});\n----\n\n{do} Mock all other resources besides the two modules being tested.\n\nFor most cases, integration interface tests are only ensuring:\n\n- Both modules can start without issues\n- The two modules don't conflict when running in the same environment (e.g. reserving the same port)\n- A few methods are able to communicate without issues\n\n[%hardbreaks]\n{do} Test interface edge-cases, like handling error {status-codel}.\n{do} Test flows that include communication between the modules.\n{do} Test sending weird data between the modules, such as non-URL-safe parameters that will be used as the URL.\n{dont} Test methods that don't communicate between modules.\n\nIn most cases, covering every possible communication isn't useful.\nFull integration tests will cover most of the useful communication,\nand unit tests will already be covering each method and making sure that each module follows the API spec.\n\nHaving duplicate assertions as unit tests for each module as well as on the interface between the two modules\nwill likely slow future development, as both assertions will have to be kept up to date with the code,\nand each module might interface with multiple modules, providing a large number of interfaces to check.\n\nHowever, fully testing the communication between two modules might make sense in two scenarios.\nMission-critical components may need the reliability,\nand integration interface tests can ensure lasting stability for components not yet in production\nand not tested in full integration tests.\n\n=== Integration Test Contents\n\nIntegration tests should evaluate the resulting application, script, or server as a whole, with limited mocking.\n\nHowever, the tests should still be run in {ava},\nso you can use tools like {supertestl} to start servers without reserving network ports.\n\n[%hardbreaks]\n{do} Write integration tests from a user's perspective.\n{do} Abstract setup of integration tests to focus test files on user-driven features.\n//{dont} Think of internal edge-cases that the user wouldn't know about.\n\nWrite as many integration tests as you need to test the different scenarios that a user might encounter.\n\n==== JSVerify for Integration Tests\n\nYou could setup {jsverifyl} to generate different flows that a user might take through your program,\nto find different edge cases.\n\n.{jsverify} Integration Test Example\n[source,js]\n----\nconst test = require(\"ava\");\nconst jsc = require(\"jsverify\");\njsc.ava = require(\"ava-verify\");\n\n// Emulates a user flow through the program:\nconst UserEnvironment = require(\"test/helpers/user-flow/UserEnvironment\");\n\n// Builds a random flow of user actions:\nconst UserFlow = require(\"test/helpers/user-flow/UserFlow\");\n\n// Builds register/login actions that are bundled:\nconst UserRegisterLogin = require(\"test/helpers/user-flow/UserRegisterLogin\");\n\ntest.beforeEach(\"start new user environment\", t =\u003e {\n  t.context.env = new UserEnvironment();\n});\n\njsc.ava({\n  suite: \"login after registration\",\n}, [\n  UserFlow.build(),\n  UserRegisterLogin.build(),\n], (t, state, [ register, login ]) =\u003e {\n  t.plan(3);\n  const { env } = t.context.env;\n  return env\n    .all(state) // Get into a random user state (with or without registering or logging in)\n    .then(env =\u003e env.do(register)) // then execute user registration\n    .then(env =\u003e env.do(login)) // then execute user login using credentials from registration\n    .then(env =\u003e {\n      // make assertions about the result from user login\n      t.is(env.code, 200, \"should result in 200 status code\");\n      t.is(env.url, \"/\", \"should navigate to homepage after login\");\n      t.true(env.headers.LOGGED_IN, \"should have 'LOGGED_IN' header\");\n    });\n});\n----\n\n=== Package Integration Test Contents\n\nThe package integration tests should make sure that the fully packaged application:\n\n- Starts\n- Does not depend on any development assets that existed during unit testing\n- Has connections to any needed resources (such as those mocked during standard integration tests)\n\nStandard integration tests should be preferred over package integration tests,\nas the extra development assets loaded into the environment can make tests\nmore efficient to process, more succinct, and more debuggable when something goes wrong.\n\n[%hardbreaks]\n{do} Execute tests in a clean environment\n{dont} Have any testing assets in the packaged environment (like `devDependencies` for {node} applications)\n\n[%hardbreaks]\n{do} Test a standard user flow through the application.\n{do} Add edge cases to cover environmental changes from the standard integration tests.\n{dont} Test user flows that can be covered as standard integration tests.\n\nFor a web-server that gets packaged into a Docker container, you could spin up the server in the container,\nthen use tools like {webdriverl} to point browser instances at the server.\n\n// TODO: Include psudocode for package integration tests.\n\n== Test File Structure\n\nAll test files should follow the same structure:\n\n[source,js]\n----\n// require/imports\n\n// before/after logic\n\n// macros\n\n// test contents\n----\n\n=== Requires/Imports\n\nUnless you have good reason for it, put all the `require()` or `import` statements at the top of the file.\n\nAVA currently comes shipped with {babell}, so you can use `import` statements with the current version of Node.\n\nIf your internal code and documentation are using `import`, you probably should use `import` statements in your testing\nfiles.\n\nFor all other use cases, we recommend using `require()` while `import` isn't natively supported in Node to reduce the\namount of transcompilation.  Either way, use a consistent syntax across your repository.\n\nRoughly order libraries from built-in to local source files.\n\n[source,js]\n----\n// Libraries needed to modify subsequent imports:\nconst Promise = require(\"bluebird\");\n// Node built-in libraries:\nconst fs = Promise.promisifyAll(require(\"fs\"));\nconst path = require(\"path\");\n// External libraries:\nconst reduce = require(\"lodash.reduce\");\nconst express = require(\"express\");\nconst request = require(\"supertest\");\n// Test setup:\nconst setup = {\n  rethink: require(\"ava-rethinkdb\"),\n};\n\n// Source files:\nconst Users = require(\"Users\");\n----\n\n=== Before/After Logic\n\nAll test setup and teardown should be done in `before`/`after` blocks.\nSetup and teardown methods can come from remote libraries or from local files.\n\n[source,js]\n----\n// Remote libraries\ntest.before(setup.rethink.init());\ntest.after.always(setup.rethink.cleanup);\n\n// Internal\ntest.beforeEach(\"create Users instance\", t =\u003e {\n  t.context.users = new Users();\n});\n----\n\n{do} Always name `before`/`after` blocks.\n\n.{dotitle} Break Tasks into Multiple Statements\n[source,js]\n----\ntest.beforeEach(\"create user\", t =\u003e {\n  t.context.user = new User(\"Bob\");\n});\n\ntest.beforeEach(\"add user to Users\", t =\u003e {\n  t.context.users.add(t.context.user);\n});\n----\n\n.{dotitle} Put Setup inside `beforeEach`\n[source,js]\n----\ntest.beforeEach(\"create server\", t =\u003e {\n  t.context.app = express();\n  app.use(myRouter);\n});\n\ntest(\"runs\", t =\u003e {\n  return request(t.context.app)\n    .get(\"/\")\n    .then(res =\u003e t.is(res.body, \"Hello World\"));\n});\n----\n\n.{donttitle} Include setup inside `test`\n[source,js]\n----\ntest(\"runs\", t =\u003e {\n  let app = express();\n  app.use(myRouter);\n  request(app);\n  return request(app)\n    .get(\"/\")\n    .then(res =\u003e t.is(res.body, \"Hello World\"));\n});\n----\n\n=== Test Macros\n\n{do} Use {ava-macrosl}!\n\nUse macros for any repeated code.\n\n.Basic Macro Usage\n[source,js]\n----\nconst add = require(\"add\");\n\nfunction adds(t, a, b, c) {\n  test.is(add(a, b), c);\n}\nadds.title = (title, a, b, c) =\u003e `add(${a}, ${b}) === ${c}`;\n\ntest(adds, 1, 2, 3);\ntest(adds, 10, 100, 110);\n----\n\nFor the most part, test macros should be simple.\n\n.{donttitle} Hide Assertions in Macros\n[source,js]\n----\nfunction gt(a, b) { return a \u003e b; }\n\nfunction gtTrue(t, a, b) {\n  if(a \u003c= b) { return t.pass(); }\n  t.true(gt(a, b));\n}\n\ntest(gtTrue, 1, 2);\ntest(gtTrue, 2, 1);\n----\n\n// TODO: \"However, some can be more complex if needed\" and include something like:\n// https://github.com/CodeLenny/modconf/blob/master/test/priorities/comparisons.js\n\n.{dotitle} Use `beforeEach` for Setup\n[source,js]\n----\ntest.beforeEach(\"creates a\", t =\u003e {\n  t.context.a = Math.random();\n});\n\nfunction checksNum(t, fn) {\n  t.true(fn(t.context.a));\n}\n\ntest(\"typeof\", checksNum, a =\u003e typeof a === \"number\");\ntest(\"isFinite\", checksNum, isFinite);\n----\n\n.{dotitle} Throw Errors if Preconditions not Met\n[source,js]\n----\ntest.beforeEach(\"connect to database\", t =\u003e {\n  t.context.db = db.connect(/* ... */);\n  if(!t.context.db.connected) {\n    throw new Error(\"Could not connect to database.\");\n  }\n});\n----\n\n=== Test Contents\n\nThe contents of the test should run code, and then use an assertion to check the output.\n\n[%hardbreaks]\n{do} Use built-in {ava-assertions}\n{do} Use {ava-planl} (`t.plan(1);`)\n\nDon't use multiple assertions when possible.\nIf you need to validate pre-conditions, test in `beforeEach` and throw an error.\n\nName tests according to the behavior they are checking.\n// TODO: include examples of test names.\n\n.{donttitle} Duplicate Test Titles\n[source,js]\n----\n// returns '200' status code\ntest(\"returns '200'\", t =\u003e {\n  return request(app)\n    .get(\"/\")\n    .then(res =\u003e {\n      t.is(res.status, 200);\n    })\n});\n----\n\n=== Missing from Test Files\n\nSome things are intentionally missing from the test files:\n\nmocks::\nMocked classes and data structures should be stored as test helpers.\nutility functions::\nFunctions that assist in constructing test data should either be run once per test (`before`/`beforeEach`)\nor stored as a test helper.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodelenny%2Fava-test-style","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcodelenny%2Fava-test-style","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodelenny%2Fava-test-style/lists"}