brut 0.0.28 → 0.1.0

data/docs/assets/deployment.md.BLseERGV.js

@@ -0,0 +1,48 @@
+import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Deployment","description":"","frontmatter":{},"headers":[],"relativePath":"deployment.md","filePath":"deployment.md"}'),t={name:"deployment.md"};function l(p,e,i,r,d,c){return s(),n("div",null,e[0]||(e[0]=[o(`<h1 id="deployment" tabindex="-1">Deployment <a class="header-anchor" href="#deployment" aria-label="Permalink to &quot;Deployment&quot;">​</a></h1><p>Brut apps are Rack apps, so they can be deployed in conventional ways.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>There are just too many ways to deploy. Brut attempts to address this by adhering to <a href="https://12factor.net" target="_blank" rel="noreferrer">12-factor principles</a>. Brut also tries not to create artifacts like <code>Procfile</code> or <code>Dockerfile</code> that would conflict with the artifacts you&#39;d need to manage deployment.</p><p>That said, Brut includes first-class support for deploying to Heroku using containers. More options will be included as necessary, either through direct support in code/tooling, or documentation here.</p><h3 id="heroku-container-based-deployment" tabindex="-1">Heroku Container-based Deployment <a class="header-anchor" href="#heroku-container-based-deployment" aria-label="Permalink to &quot;Heroku Container-based Deployment&quot;">​</a></h3><p>When creating your Brut app with <code>mkbrut</code>, the Heroku segment can be used to create files and scripts for a <a href="https://devcenter.heroku.com/articles/container-registry-and-runtime" target="_blank" rel="noreferrer">Heroku container-based deployment</a>.</p><table tabindex="0"><thead><tr><th>File</th><th>Purpose</th><th>Notes</th></tr></thead><tbody><tr><td><code>bin/deploy</code></td><td>Script to use to perform the deployment</td><td>This wraps <code>HerokuContainerBasedDeploy</code> in <a href="/api/Brut/CLI/Apps.html" target="_self" rel="noopener" data-no-router><code>Brut::CLI::Apps</code></a></td></tr><tr><td><code>deploy/Dockerfile</code></td><td>Template <code>Dockerfile</code> used to create a <code>Dockerfile</code> for each process type</td><td>Heroku requires each process (web, worker, release, etc.) to have its own <code>Dockerfile</code> and own image</td></tr><tr><td><code>deploy/heroku_config.rb</code></td><td>Class that exports optional processes</td><td>By default, your app has a web and release process. <code>HerokuConfig</code> can export others, like Sidekiq</td></tr><tr><td><code>deploy/docker-entrypoint</code></td><td>The <a href="https://docs.docker.com/reference/dockerfile/#entrypoint" target="_blank" rel="noreferrer"><code>ENTRYPOINT</code></a> for production Docker images, which is set up to use jemalloc</td><td>You can modify or remove this as needed</td></tr></tbody></table><p>How to deploy:</p><ol><li><p>Auth to Heroku from inside your dev container:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>your-computer&gt; dx/exec bash</span></span>
+<span class="line"><span>devcontainer&gt; heroku auth:login</span></span>
+<span class="line"><span># You will need to copy/paste the URL to log in</span></span>
+<span class="line"><span>devcontainer&gt; heroku container:login</span></span></code></pre></div></li><li><p>Create your app using the container stack:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; heroku create --stack container -a «your heroku app name»</span></span></code></pre></div></li><li><p>Ensure your app&#39;s source code is all checked in, there are no uncommitted or unadded files, and you have pushed to main.</p></li><li><p><code>bin/deploy</code></p><p>This will generate a <code>Dockerfile</code> for each process (by default, <code>Dockerfile.web</code> and <code>Dockerfile.release</code>), build images, push those images to Heroku, and ask Heroku to release them.</p></li></ol><p>Debugging Tips:</p><ul><li><p>Keep in mind it&#39;s hard to make general deployment tools. You are expected to understand your deployment and be capable of deploying an arbitrary Rack app manually. Brut&#39;s tooling automates what you need to know.</p></li><li><p><code>bin/deploy</code> runs the <code>deploy</code> subcommand, so <code>bin/deploy help deploy</code> can provide some options for debugging issues:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>devcontainer&gt; bin/deploy help deploy</span></span>
+<span class="line"><span>Usage: bin/deploy [global options] deploy [command options] </span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    Build images, push them to Heroku, and deploy them</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    Manages a deploy process based on using Heroku&#39;s Container Registry. See</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    https://devcenter.heroku.com/articles/container-registry-and-runtime</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    for details. You are assumed to understand this.</span></span>
+<span class="line"><span>    This command will make the process somewhat easier.</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    This will use deploy/Dockerfile as a template to create</span></span>
+<span class="line"><span>    one Dockerfile for each process you want to run in Heroku.</span></span>
+<span class="line"><span>    deploy/heroku_config.rb is where the processes and their</span></span>
+<span class="line"><span>    commands are configured.</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    The release phase is included automatically, based on bin/release.</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>GLOBAL OPTIONS</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    -h, --help            Get help</span></span>
+<span class="line"><span>        --log-level=LEVEL Set log level. Allowed values: debug,</span></span>
+<span class="line"><span>                          info, warn, error, fatal. Default &#39;fatal&#39;</span></span>
+<span class="line"><span>        --verbose         Set log level to &#39;debug&#39;, which will produce</span></span>
+<span class="line"><span>                          maximum output</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>ENVIRONMENT VARIABLES</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>    BRUT_CLI_RAISE_ON_ERROR - if set, shows backtrace on errors</span></span>
+<span class="line"><span>    LOG_LEVEL               - log level if --log-level or --verbose is omitted</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>COMMAND OPTIONS</span></span>
+<span class="line"><span></span></span>
+<span class="line"><span>        --platform=PLATFORM  Override default platform. Can be any Docker</span></span>
+<span class="line"><span>                             platform.</span></span>
+<span class="line"><span>        --[no-]dry-run       Print the commands that would be run and</span></span>
+<span class="line"><span>                             don&#39;t actually do anything. Implies --skip-checks</span></span>
+<span class="line"><span>        --[no-]skip-checks   Skip checks for code having been</span></span>
+<span class="line"><span>                             committed and pushed</span></span>
+<span class="line"><span>        --[no-]deploy        After images are pushed, actually deploy them</span></span>
+<span class="line"><span>        --[no-]push          After images are created, push them</span></span>
+<span class="line"><span>                             to Heroku&#39;s registry. If false,</span></span>
+<span class="line"><span>                             implies --no-deploy</span></span></code></pre></div></li><li><p>Try building images first: <code>bin/deploy deploy --no-push --skip-checks</code></p></li><li><p>It&#39;s possible to run the images locally. If you are on Apple Silicon, you&#39;ll need to set --platform:</p><ul><li><code>bin/deploy deploy --no-push --skip-checks --platform linux/arm64</code></li><li>Create <code>docker-compose.yml</code> for your image and any other services e.g. databases</li><li>Set required environment variables in <code>docker-compose.yml</code></li><li>Start up Docker compose and poke around</li></ul><p>You&#39;ll need to have a better understanding of Docker to do this, however if you are deploying with Docker, this is an understanding you hopefully already have.</p></li></ul><h3 id="other-mechanisms-for-deployment" tabindex="-1">Other Mechanisms for Deployment <a class="header-anchor" href="#other-mechanisms-for-deployment" aria-label="Permalink to &quot;Other Mechanisms for Deployment&quot;">​</a></h3><p>As a Rack app, other deployments should be possible. To make the app work, you&#39;ll need to make sure a few things are dealt with:</p><ul><li><code>RACK_ENV</code> <strong>must</strong> be <code>&quot;production&quot;</code></li><li><code>bin/build-assets</code> will build all assets by default. This must either be done on production servers or done ahead of time and the results packaged with the app.</li><li><code>bin/build-assets</code> outputs files in <code>app/public</code> and <code>app/config</code>. Those files are used at runtime. Brut <strong>will not</strong> initiate the build of any assets.</li><li>If you are going to build assets on production servers, you <em>must</em> included developer tooling. This means NodeJS, all modules in <code>package.json</code> and all RubyGems in <code>Gemfile</code>.</li></ul><p>The <code>deploy/Dockerfile</code> created by <code>mkbrut --segment-heroku</code> is not very Heroku-specific and could serve as a reference.</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Testing deployments is a bit out of scope, but in general:</p><ul><li>A container-based deployment can theoretically be run on your computer as a test.</li><li>Non-production, but production-like environments can be used to validate production configurations.</li><li>You own the means of production…not Brut.</li></ul><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><ul><li>Avoid a lot of code that checks <code>Brut.container.project_env</code>. Try to consolidate all prod/test/dev differences in environment variables.</li><li>Have a way to get a shell into your production environment for debugging.</li><li>Brut doesn&#39;t log much, but if you remove the <code>OTEL_*</code> environment variables, Brut will log OTel telemetry to the console, which may be useful.</li><li>Setting <code>OTEL_LOG_LEVEL=debug</code> is advised if the app isn&#39;t starting or you aren&#39;t seeing any telemetry or logging</li></ul><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated July 3, 2025</em></p><p>None at this time.</p>`,25)]))}const m=a(t,[["render",l]]);export{h as __pageData,m as default};

data/docs/assets/deployment.md.BLseERGV.lean.js

@@ -0,0 +1 @@
+import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Deployment","description":"","frontmatter":{},"headers":[],"relativePath":"deployment.md","filePath":"deployment.md"}'),t={name:"deployment.md"};function l(p,e,i,r,d,c){return s(),n("div",null,e[0]||(e[0]=[o("",25)]))}const m=a(t,[["render",l]]);export{h as __pageData,m as default};

data/docs/assets/dev-environment.md.BroAOLhF.js

@@ -0,0 +1,11 @@
+import{_ as t,c as a,o as s,ag as i}from"./chunks/framework.1L-BeKqY.js";const o="/assets/dev-env-overview.Gj7NWM8-.png",n="/assets/dev-env-protocol.DysDAtnz.png",d="/assets/workspace-protocol.C0gXsoDb.png",g=JSON.parse('{"title":"Dev Environment","description":"","frontmatter":{},"headers":[],"relativePath":"dev-environment.md","filePath":"dev-environment.md"}'),r={name:"dev-environment.md"};function l(c,e,p,h,u,m){return s(),a("div",null,e[0]||(e[0]=[i('<h1 id="dev-environment" tabindex="-1">Dev Environment <a class="header-anchor" href="#dev-environment" aria-label="Permalink to &quot;Dev Environment&quot;">​</a></h1><p>Brut provides sophisticated tooling to manage your dev environment</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>A development environments or <em>dev environment</em> is made up of two parts:</p><ul><li><em>Foundational Core</em> - the operating system and tools needed to run the app and <em>its</em> tools. This includes language runtimes, system libraries (like ImageMagick), and system tools like web browsers.</li><li><em>Workspace</em> - the tools and code bundled with the app that you use day-to-day to work on the app itself. This would include scripts to run the app in development, run tests, perform scaffolding, or manage the database.</li></ul><p>On many teams, the Foundational Core is different per developer, since some run Linux, some run MacOs. Some might use mise to manage their version of Ruby while others use rbenv. Some will set up Postgres via homebrew, while others might use Popstgres.app.</p><p>Brut takes a different approach. Everyone shares the same Foundational Core, and this is defined by a <code>Dockerfile</code>, a <code>docker-compose.yml</code> file, and some lightweight Bash scripts.</p><p>This means that everyone uses the same version of everything, and they are all managed the same way.</p><p>Brut also provides sophisticated tooling for the Workspace. Like Rails, Brut provides a command-line based flow that can be scripted into any editor. Unlike Rails, Brut&#39;s Workspace is comprised of separate command-line apps and not Rake tasks.</p><h3 id="conceptual-overview" tabindex="-1">Conceptual Overview <a class="header-anchor" href="#conceptual-overview" aria-label="Permalink to &quot;Conceptual Overview&quot;">​</a></h3><p>Your dev environment consists of a Docker container that has languages, an operating system, and other system components installed in it. It will have access to the files on your computer so that it can run your app. The app will be exposed so that a browser on your computer can access it. Postgres will be run as a separate Docker container available to the dev Docker container.</p><p>Your editor and version control system run on your computer.</p><p><img src="'+o+'" alt="Conceptual Overview"></p><h3 id="foundational-core-command-line-apps" tabindex="-1">Foundational Core Command Line Apps <a class="header-anchor" href="#foundational-core-command-line-apps" aria-label="Permalink to &quot;Foundational Core Command Line Apps&quot;">​</a></h3><p>These are the commands you will use to manage the <em>foundational core</em>, which is the Docker containers and their contents.</p><p>A few brief terminology notes if you aren&#39;t familiar with Docker:</p><ul><li>A Docker <em>container</em> is akin to a virtual machine. On Linux this isn&#39;t strictly true, but conceptually, you can think of this like a virtual computer.</li><li>A Docker <em>image</em> is what you use to start a container. This is akin to a disk image you might use to create a new computer or virtual machine.</li><li>A Dockerfile (often named <code>Dockerfile</code>) is a set of instructions to create an image.</li></ul><p>A few verbs to provide additional help:</p><ul><li>One <em>builds</em> a Docker image from a Dockerfile.</li><li>One <em>starts</em> a Docker container from an image.</li><li>One <em>stops</em> a Docker container when it&#39;s no longer needed.</li></ul><table tabindex="0"><thead><tr><th>App</th><th>Purpose</th></tr></thead><tbody><tr><td><code>dx/build</code></td><td>Builds a Docker <em>image</em> from a <code>Dockerfile.dx</code></td></tr><tr><td><code>dx/start</code></td><td>Starts all Docker containers, including those for databases and caches</td></tr><tr><td><code>dx/stop</code></td><td>Stops all Docker containers</td></tr><tr><td><code>dx/exec</code></td><td>Execute a command inside a running Docker container</td></tr></tbody></table><p>The workflow for the foundational core is shown in this diagram.</p><p><img src="'+n+'" alt="Foundational Core Workflow"></p><p>In words:</p><ol><li>You build the images based on the latest instructions via <code>dx/build</code>.</li><li>You start up the environment with <code>dx/start</code>.</li><li>You then use <code>dx/exec</code> to execute commands from the Workspace (see below).</li><li>When you are done working for the day, <code>dx/stop</code> shuts everything down.</li></ol><h3 id="workspace-command-line-apps" tabindex="-1">Workspace Command Line Apps <a class="header-anchor" href="#workspace-command-line-apps" aria-label="Permalink to &quot;Workspace Command Line Apps&quot;">​</a></h3><p>The workspace is where you&#39;ll run your day-to-day commands, such as running tests, starting the dev server, managing the database schema, etc.</p><p>Several of the commands accept or require subcommands. Each CLI app responds to <code>--help</code> and will show you full documentation about what the command and subcommands do.</p><table tabindex="0"><thead><tr><th>App</th><th>Subcommand</th><th>Descriptions</th></tr></thead><tbody><tr><td><code style="white-space:nowrap;">bin/ci</code></td><td>None</td><td>Runs all tests and security checks</td></tr><tr><td><code style="white-space:nowrap;">bin/console</code></td><td>None</td><td>Starts up a local IRB session with your app loaded</td></tr><tr><td><code style="white-space:nowrap;">bin/db</code></td><td></td><td>Tools for managing the database</td></tr><tr><td></td><td><code>create</code></td><td>Create the database if it does not exist</td></tr><tr><td></td><td><code>drop</code></td><td>Drop the database if it exists</td></tr><tr><td></td><td><code>migrate</code></td><td>Apply any outstanding migrations to the database</td></tr><tr><td></td><td><code>new_migration</code></td><td>Create a new migration file</td></tr><tr><td></td><td><code>rebuild</code></td><td>Drop, re-create, and run migrations, effectively rebuilding the entire database</td></tr><tr><td></td><td><code>seed</code></td><td>Load seed data into the database</td></tr><tr><td></td><td><code>status</code></td><td>Check the status of the database and migrations</td></tr><tr><td><code style="white-space:nowrap;">bin/dbconsole</code></td><td>None</td><td>Starts up a <code>psql</code> session to your database</td></tr><tr><td><code style="white-space:nowrap;">bin/dev</code></td><td>None</td><td>Starts the app in dev mode, rebuilding assets and reload as needed</td></tr><tr><td><code style="white-space:nowrap;">bin/setup</code></td><td>None</td><td>Install and setup all third party libraries and other configuration needed to use the app</td></tr><tr><td><code style="white-space:nowrap;">bin/scaffold</code></td><td></td><td>Generate Brut classes or files like database migrations or page classes</td></tr><tr><td></td><td><code>action</code></td><td>Create a handler for an action</td></tr><tr><td></td><td><code>component</code></td><td>Create a new component and associated test</td></tr><tr><td></td><td><code>custom_element_test</code></td><td>Create a test for a custom element in your app</td></tr><tr><td></td><td><code>form</code></td><td>Create a form and handler</td></tr><tr><td></td><td><code>page</code></td><td>Create a new page and associated test</td></tr><tr><td></td><td><code>test</code></td><td>Create the shell of a unit test based on an existing source file</td></tr><tr><td></td><td><code>test:e2e</code></td><td>Create the shell of an end-to-end test</td></tr><tr><td><code style="white-space:nowrap;">bin/test</code></td><td></td><td>Run tests</td></tr><tr><td></td><td><code>audit</code></td><td>Audits all of the app&#39;s classes to see if test files exist</td></tr><tr><td></td><td><code>e2e</code></td><td>Run e2e tests</td></tr><tr><td></td><td><code>js</code></td><td>Run JavaScript unit tests</td></tr><tr><td></td><td><code>run</code></td><td>Run non-e2e tests (default)</td></tr></tbody></table><p>The workflow for your Workspace is shown in this diagram</p><p><img src="'+d+`" alt="Workspace Workflow"></p><p>In words:</p><ol><li>You&#39;ll run <code>bin/setup</code> to get everything set up for working.</li><li>You&#39;ll start your dev server with <code>bin/dev</code>.</li><li>You&#39;ll write code, using tools like <code>bin/db</code> and <code>bin/scaffold</code> to assist.</li><li>Using <code>bin/test</code>, you can test any code you&#39;ve written a test for.</li><li>When you are at a stopping point, use <code>bin/ci</code> to test the entire app.</li></ol><h3 id="extending-and-enhancing" tabindex="-1">Extending and Enhancing <a class="header-anchor" href="#extending-and-enhancing" aria-label="Permalink to &quot;Extending and Enhancing&quot;">​</a></h3><p>TBD</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>There aren&#39;t tests for this code, because you are using all day every day. Brut&#39;s test suite will ensure that the versions of these command line apps provided when you set up your app are working.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>While you are free to set up mise or rbenv or whatever to run all this on your computer, this way of working is currently not supported nor encouraged. For now, Brut will focus on the Docker-based approach.</p><p>The primary reason is that it&#39;s a tightly controlled environment that is almost entirely scriptable, but does not require devs to abandon their preferred editor. Environment manager-based approaches tend to be more fussy and require documentation to ensure they are set up.</p><p>Keep in mind a few things when adding your own automation:</p><ul><li>The <em>Foundational Core</em> is bootstrapped in a degenerate environment without reliable tools beyond Bash. This is why it&#39;s almost entirely written in Bash, since it&#39;s available everywhere and relatively stable.</li><li>The <em>Workspace</em> <strong>can and should</strong> rely on the languages and third party modules that are part of your app. The only exception is <code>bin/setup</code>, since it installs third party modules. As such, it should work entirely based on Ruby and its standard library.</li></ul><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 12, 2025</em></p><p>Everything in <code>bin/</code> is intended to be a short shim that calls into classes managed either by Brut or by your app. For example, here is <code>bin/db</code>:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">#!/usr/bin/env ruby</span></span>
+<span class="line"></span>
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;bundler&quot;</span></span>
+<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Bundler</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">require</span></span>
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;pathname&quot;</span></span>
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;brut/cli/apps/db&quot;</span></span>
+<span class="line"></span>
+<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">exit</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">CLI</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">app</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
+<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">       Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">CLI</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Apps</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">DB</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
+<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">       project_root:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Pathname</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">($0).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">dirname</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> /</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;..&quot;</span></span>
+<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">     )</span></span></code></pre></div><p>These files have some duplication, but should be relatively stable.</p><p>This means that Brut-provided CLIs <em>will</em> be updated when you update Brut. Compare this to the files in <code>dx/</code> which are entire Bash scripts that will not be updated when Brut is updated.</p>`,48)]))}const y=t(r,[["render",l]]);export{g as __pageData,y as default};

data/docs/assets/dir-structure.md.CWir1pic.js

@@ -0,0 +1,46 @@
+import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Directory Structure","description":"","frontmatter":{},"headers":[],"relativePath":"dir-structure.md","filePath":"dir-structure.md"}'),d={name:"dir-structure.md"};function o(p,s,c,r,l,i){return e(),t("div",null,s[0]||(s[0]=[n(`<h1 id="directory-structure" tabindex="-1">Directory Structure <a class="header-anchor" href="#directory-structure" aria-label="Permalink to &quot;Directory Structure&quot;">​</a></h1><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>.</span></span>
+<span class="line"><span>├── app</span></span>
+<span class="line"><span>│   ├── config</span></span>
+<span class="line"><span>│   │   └── i18n</span></span>
+<span class="line"><span>│   │       └── en</span></span>
+<span class="line"><span>│   ├── public</span></span>
+<span class="line"><span>│   │   ├── css</span></span>
+<span class="line"><span>│   │   ├── js</span></span>
+<span class="line"><span>│   │   └── static</span></span>
+<span class="line"><span>│   │       └── images</span></span>
+<span class="line"><span>│   └── src</span></span>
+<span class="line"><span>│       ├── back_end</span></span>
+<span class="line"><span>│       │   ├── data_models</span></span>
+<span class="line"><span>│       │       ├── db</span></span>
+<span class="line"><span>│       │       ├── migrations</span></span>
+<span class="line"><span>│       │       └── seed</span></span>
+<span class="line"><span>│       ├── cli</span></span>
+<span class="line"><span>│       └── front_end</span></span>
+<span class="line"><span>│           ├── components</span></span>
+<span class="line"><span>│           ├── css</span></span>
+<span class="line"><span>│           ├── fonts</span></span>
+<span class="line"><span>│           ├── forms</span></span>
+<span class="line"><span>│           ├── handlers</span></span>
+<span class="line"><span>│           ├── images</span></span>
+<span class="line"><span>│           ├── js</span></span>
+<span class="line"><span>│           ├── layouts</span></span>
+<span class="line"><span>│           ├── pages</span></span>
+<span class="line"><span>│           ├── route_hooks</span></span>
+<span class="line"><span>│           ├── support</span></span>
+<span class="line"><span>│           └── svgs</span></span>
+<span class="line"><span>├── bin</span></span>
+<span class="line"><span>├── deploy</span></span>
+<span class="line"><span>├── dx</span></span>
+<span class="line"><span>└── specs</span></span>
+<span class="line"><span>    ├── back_end</span></span>
+<span class="line"><span>    │   ├── data_models</span></span>
+<span class="line"><span>    │       └── db</span></span>
+<span class="line"><span>    ├── e2e</span></span>
+<span class="line"><span>    ├── factories</span></span>
+<span class="line"><span>    │   └── db</span></span>
+<span class="line"><span>    └── front_end</span></span>
+<span class="line"><span>        ├── components</span></span>
+<span class="line"><span>        ├── handlers</span></span>
+<span class="line"><span>        ├── js</span></span>
+<span class="line"><span>        ├── pages</span></span>
+<span class="line"><span>        └── support</span></span></code></pre></div><h2 id="top-level" tabindex="-1">Top Level <a class="header-anchor" href="#top-level" aria-label="Permalink to &quot;Top Level&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app/</code></td><td>Contains all configuration and source code specific to your app</td></tr><tr><td><code>bin/</code></td><td>Contains tasks and other CLIs to do development of your app, such as <code>bin/test</code></td></tr><tr><td><code>dx/</code></td><td>Contains scripts to manage your development environment</td></tr><tr><td><code>specs/</code></td><td>Contains all tests</td></tr></tbody></table><h2 id="inside-app" tabindex="-1">Inside <code>app</code>/ <a class="header-anchor" href="#inside-app" aria-label="Permalink to &quot;Inside \`app\`/&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>bootstrap.rb</code></td><td>A ruby file that sets up your app and ensures everything is <code>require</code>d in the right way.</td></tr><tr><td><code>config/</code></td><td>Configuration for your app, such as localizations and translations. Brut tries very hard to make sure there is no YAML in here at all. YAML is not good for you.</td></tr><tr><td><code>public/</code></td><td>Root of public assets served by the app.</td></tr><tr><td><code>src/</code></td><td>All source code for your app</td></tr></tbody></table><p>Inside <code>app/src</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app.rb</code></td><td>The core of your app, mostly configuration, such as routes, hooks, middleware, etc.</td></tr><tr><td><code>back_end/</code></td><td>Back end classes for your app including database schema, DB models, seed data, and your domain logic</td></tr><tr><td><code>cli/</code></td><td>Any CLIs or tasks for your app</td></tr><tr><td><code>front_end/</code></td><td>The front-end for your app, including pages, components, forms, handlers, JavaScript, and assets</td></tr></tbody></table><p>Inside <code>app/src/back_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>data_models/app_data_model.rb</code></td><td>Base class for all DB model classes</td></tr><tr><td><code>data_models/db</code></td><td>DB model classes</td></tr><tr><td><code>data_models/db.rb</code></td><td>Namespace module for DB model classes</td></tr><tr><td><code>data_models/migrations</code></td><td>Database schema migrations</td></tr><tr><td><code>data_models/seed</code></td><td>Seed data used for local development</td></tr></tbody></table><p>Inside <code>app/src/front_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>components/</code></td><td>Component classes</td></tr><tr><td><code>css/</code></td><td>CSS, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>fonts/</code></td><td>Custom fonts, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>forms/</code></td><td>Form classes</td></tr><tr><td><code>handlers/</code></td><td>Handler classes</td></tr><tr><td><code>images/</code></td><td>Images, copied to <code>app/public</code> by <code>bin/build-assets</code></td></tr><tr><td><code>js/</code></td><td>JavaScript, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>layouts/</code></td><td>Layout classes</td></tr><tr><td><code>middlewares/</code></td><td>Rack Middleware, if any</td></tr><tr><td><code>pages/</code></td><td>Page classes</td></tr><tr><td><code>route_hooks/</code></td><td>Route hooks, if any</td></tr><tr><td><code>support/</code></td><td>General support classes/junk drawer.</td></tr><tr><td><code>svgs/</code></td><td>SVGs you want to render inline</td></tr></tbody></table><h2 id="inside-specs" tabindex="-1">Inside <code>specs/</code> <a class="header-anchor" href="#inside-specs" aria-label="Permalink to &quot;Inside \`specs/\`&quot;">​</a></h2><p><code>specs/</code> is intended to mirror <code>app/src</code>, but has a few extra directories:</p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>specs/back_end</code></td><td>tests for all back-end code, organized the same as <code>app/src/back_end</code></td></tr><tr><td><code>specs/back_end/data_models/db</code></td><td>tests for all DB classes, if needed</td></tr><tr><td><code>specs/e2e</code></td><td>End-to-end tests, organized however you like</td></tr><tr><td><code>specs/factories</code></td><td>Root of all factories for FactoryBot. You can create subdirectories here for non-DB classes you may want to be able to create</td></tr><tr><td><code>specs/factories/db</code></td><td>Factories to create DB records</td></tr><tr><td><code>specs/front_end</code></td><td>tests for all front-end code, organized the same as <code>app/src/front_end</code></td></tr><tr><td><code>specs/js</code></td><td><em>JavaScript</em> code to test any autonomous custom elements you have created</td></tr></tbody></table>`,15)]))}const b=a(d,[["render",o]]);export{h as __pageData,b as default};

data/docs/assets/dir-structure.md.CWir1pic.lean.js

@@ -0,0 +1 @@
+import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Directory Structure","description":"","frontmatter":{},"headers":[],"relativePath":"dir-structure.md","filePath":"dir-structure.md"}'),d={name:"dir-structure.md"};function o(p,s,c,r,l,i){return e(),t("div",null,s[0]||(s[0]=[n("",15)]))}const b=a(d,[["render",o]]);export{h as __pageData,b as default};

data/docs/assets/doc-conventions.md.BzmSrTEW.js

@@ -0,0 +1 @@
+import{_ as t,c as o,o as s,ag as r}from"./chunks/framework.1L-BeKqY.js";const m=JSON.parse('{"title":"Documentation Conventions","description":"","frontmatter":{},"headers":[],"relativePath":"doc-conventions.md","filePath":"doc-conventions.md"}'),n={name:"doc-conventions.md"};function a(i,e,l,u,c,d){return s(),o("div",null,e[0]||(e[0]=[r('<h1 id="documentation-conventions" tabindex="-1">Documentation Conventions <a class="header-anchor" href="#documentation-conventions" aria-label="Permalink to &quot;Documentation Conventions&quot;">​</a></h1><h2 id="terminology" tabindex="-1">Terminology <a class="header-anchor" href="#terminology" aria-label="Permalink to &quot;Terminology&quot;">​</a></h2><p>Brut attempts to use existing terminology where possible, particularly where that technology applies to the web platform. For example, there is not a thing called &quot;CSS variables&quot;, rather the term is &quot;custom properties&quot;.</p><p>Here are some common exampels:</p><ul><li>HTML entities are <strong>elements</strong> or <strong>tags</strong></li><li>HTML elements have <strong>attributes</strong>.</li><li>Forms don&#39;t have validations, they have <strong>constraints</strong> which are <strong>violated</strong> by invalid data.</li><li>Ruby classes don&#39;t have constructors, they have <strong>initializers</strong>.</li><li>Invoking behavior on a Ruby object is <strong>calling a method</strong>, not sending a message.</li><li>Despite being in <code>specs/</code>, the files in there are <strong>tests</strong>, not specifications or -specs&quot;.</li><li>Tests that use a browser are <strong>end to end</strong> or <strong>e2e</strong> tests.</li><li>HTML is not rendered, but <strong>generated</strong>. The browser renders the HTML sent to it by the server, along with the CSS.</li><li>Your app or site doesn&#39;t have users, it has <strong>visitors</strong>.</li></ul><h2 id="structure-of-these-documents" tabindex="-1">Structure of These Documents <a class="header-anchor" href="#structure-of-these-documents" aria-label="Permalink to &quot;Structure of These Documents&quot;">​</a></h2><p>Each page here documents on aspect of Brut, called a <em>module</em>, and these pages are organized along four sections:</p><ul><li><strong>Overview</strong> - What the module does, how it works, and a brief example.</li><li><strong>Testing</strong> - How to test the code you write in this module.</li><li><strong>Recommended Practices</strong> - Opinions from the creators about how best to think about the code in this module.</li><li><strong>Technical Notes</strong> - details about the technical implementations that may be useful as context.</li></ul><h2 id="names-of-the-library-and-associated-modules" tabindex="-1">Names of the Library and Associated Modules <a class="header-anchor" href="#names-of-the-library-and-associated-modules" aria-label="Permalink to &quot;Names of the Library and Associated Modules&quot;">​</a></h2><p>This framework is called &quot;Brut&quot; though may be called &quot;BrutRB&quot; or &quot;brut-rp&quot;. It lives at <code>brutrb.com</code>. Never use &quot;brutRB&quot;, &quot;brut_rb&quot;, etc.</p><p>The JavaScript library is called &quot;BrutJS&quot;, but is <code>brut-js</code> in code or the filesystem. &quot;Brut-JS&quot; is wrong, as is <code>brut_js</code>.</p><p>The CSS library is called &quot;BrutCSS&quot;, but is <code>brut-css</code> in code or the filesystem. &quot;Brut-CSS&quot; is wrong, as is &quot;brut-css&quot;.</p><h2 id="on-using-vitepress" tabindex="-1">On Using VitePress <a class="header-anchor" href="#on-using-vitepress" aria-label="Permalink to &quot;On Using VitePress&quot;">​</a></h2><p>This site is built using <a href="https://vitepress.dev" target="_blank" rel="noreferrer">VitePress</a>, which is a client-side heavy framework. It kinda goes against the ethos of Brut, but it is allowing me to write documentation that looks decent and is mostly navigable. I would like to use a more accessible, customized system for documenting Brut, but for now, it&#39;s more important to get the documentation out. A better documentation experience is planned.</p>',14)]))}const g=t(n,[["render",a]]);export{m as __pageData,g as default};

data/docs/assets/doc-conventions.md.BzmSrTEW.lean.js

@@ -0,0 +1 @@
+import{_ as t,c as o,o as s,ag as r}from"./chunks/framework.1L-BeKqY.js";const m=JSON.parse('{"title":"Documentation Conventions","description":"","frontmatter":{},"headers":[],"relativePath":"doc-conventions.md","filePath":"doc-conventions.md"}'),n={name:"doc-conventions.md"};function a(i,e,l,u,c,d){return s(),o("div",null,e[0]||(e[0]=[r("",14)]))}const g=t(n,[["render",a]]);export{m as __pageData,g as default};

data/docs/assets/{end-to-end-tests.md.yfQHC0b5.js → end-to-end-tests.md.DzqRpZ43.js}

@@ -1,4 +1,4 @@
-import{_ as s,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const u=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(r,e,l,h,p,d){return a(),t("div",null,e[0]||(e[0]=[i(`<h1 id="end-to-end-tests" tabindex="-1">End to End Tests <a class="header-anchor" href="#end-to-end-tests" aria-label="Permalink to &quot;End to End Tests&quot;">​</a></h1><p>Is there a greater pain the world than an end-to-end test? Is there a more punishing API than trying to convince a browser to browse and use a website? Is there an answer for why the way we interact with browsers when writing code is 100% different than the we do when writing a test?</p><p>Brut cannot answer these things, but it does provide a way to write end-to-end tests with a browser, with a somewhat slightly reduced amount of pain.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Brut uses <a href="https://playwright.dev/" target="_blank" rel="noreferrer">Playwright</a> and the <a href="https://playwright-ruby-client.vercel.app/" target="_blank" rel="noreferrer">playwright-ruby-client</a> to allow you to write end-to-end tests that use a web browser. Brut sets up headless Chromium to do this.</p><p>You can run End-to-End (e2e) tests with <code>bin/test e2e</code>. You must use this to run individual tests as well, since this will ensure proper set up for the tests, which is more than is needed for a normal unit test.</p><h3 id="using-playwright" tabindex="-1">Using Playwright <a class="header-anchor" href="#using-playwright" aria-label="Permalink to &quot;Using Playwright&quot;">​</a></h3><p>At a high level, e2e tests look like normal RSpec tests:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;spec_helper&quot;</span></span>
+import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const k=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(l,s,h,r,p,d){return a(),t("div",null,s[0]||(s[0]=[i(`<h1 id="end-to-end-tests" tabindex="-1">End to End Tests <a class="header-anchor" href="#end-to-end-tests" aria-label="Permalink to &quot;End to End Tests&quot;">​</a></h1><p>Is there a greater pain the world than an end-to-end test? Is there a more punishing API than trying to convince a browser to browse and use a website? Is there an answer for why the way we interact with browsers when writing code is 100% different than the we do when writing a test?</p><p>Brut cannot answer these things, but it does provide a way to write end-to-end tests with a browser, with a somewhat slightly reduced amount of pain.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Brut uses <a href="https://playwright.dev/" target="_blank" rel="noreferrer">Playwright</a> and the <a href="https://playwright-ruby-client.vercel.app/" target="_blank" rel="noreferrer">playwright-ruby-client</a> to allow you to write end-to-end tests that use a web browser. Brut sets up headless Chromium to do this.</p><p>You can run End-to-End (e2e) tests with <code>bin/test e2e</code>. You must use this to run individual tests as well, since this will ensure proper set up for the tests, which is more than is needed for a normal unit test.</p><h3 id="using-playwright" tabindex="-1">Using Playwright <a class="header-anchor" href="#using-playwright" aria-label="Permalink to &quot;Using Playwright&quot;">​</a></h3><p>At a high level, e2e tests look like normal RSpec tests:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;spec_helper&quot;</span></span>
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">RSpec</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">describe</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;logging into the website&quot;</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> do</span></span>
 <span class="line"></span>
@@ -21,6 +21,8 @@ import{_ as s,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const u
 <span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">    flash</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> = page.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">locator</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;[role=&#39;alert&#39;]&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span>
 <span class="line"><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">    expect</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(flash).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">to</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> have_text</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;No email/password in our system&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  end</span></span>
-<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p><code>playwright-ruby-client</code> provides excellent documentation on how it has adapter Playwright&#39;s API for use in Ruby.</p><h3 id="test-setup" tabindex="-1">Test Setup <a class="header-anchor" href="#test-setup" aria-label="Permalink to &quot;Test Setup&quot;">​</a></h3><p>Brut will run your app via <a href="/api/Brut/SpecSupport/E2ETestServer.html" target="_self" rel="noopener" data-no-router><code>Brut::SpecSupport::E2ETestServer</code></a>. It will run it before the first e2e test, leave it running during the remainder of the test suite, then stop it. This means that database changes your test makes will persist across tests.</p><p>If you are using Sidekiq, Sidekiq will be set up like normal. Jobs queued will go to Redis, and those jobs will be processed by Sidekiq, just like in production. Thus, you should not assert things about specific jobs, but rather assert the effects those jobs will have. Redis is flushed between each test.</p><h3 id="test-helpers-and-configuration" tabindex="-1">Test Helpers and Configuration <a class="header-anchor" href="#test-helpers-and-configuration" aria-label="Permalink to &quot;Test Helpers and Configuration&quot;">​</a></h3><p>Inside your test, <code>t</code> is available to produce translations. You can also access all your page and handler classes, so you can (and should) use <code>.routing</code>, e.g. <code>DashboardPage.routing</code>, to generate or access routes for your app.</p><p>You can set <code>e2e_timeout</code> on any test to override the default amount of time Playwright will wait for a locator to locate an element. The default is 5 seconds. \`, to generate or access routes for your app. You can also configure behavior with environment variables:</p><table tabindex="0"><thead><tr><th>Variable</th><th>Default</th><th>Purpose</th></tr></thead><tbody><tr><td><code>E2E_TIMEOUT_MS</code></td><td>5000</td><td>Number of milliseconds Playwright will wait for a locator to appear</td></tr><tr><td><code>E2E_SLOW_MO</code></td><td>0</td><td>Number of milliseconds Playwright will pause between operations. Useful to detect race conditions</td></tr><tr><td><code>E2E_RECORD_VIDEOS</code></td><td>unset</td><td>If set, videos of each test run are saved in <code>tmp/e2e-videos</code></td></tr></tbody></table><h3 id="quirks-of-playwright" tabindex="-1">Quirks of Playwright <a class="header-anchor" href="#quirks-of-playwright" aria-label="Permalink to &quot;Quirks of Playwright&quot;">​</a></h3><p>The Playwright JavaScript API is heavily asycnhronous, requiring liberal use of <code>await</code>. The <code>playwright-ruby-client</code> wrapper abstracts that so you can write more straightfoward code.</p><p>The main thing to be aware of is that locators that fail only fail when you attempt to assert something.</p><p>For example</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">button</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> = page.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">locator</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;form button&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">) </span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># suppose this button doesn&#39;t exist</span></span>
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p><code>playwright-ruby-client</code> provides excellent documentation on how it has adapted Playwright&#39;s API for use in Ruby.</p><h3 id="test-setup" tabindex="-1">Test Setup <a class="header-anchor" href="#test-setup" aria-label="Permalink to &quot;Test Setup&quot;">​</a></h3><p>Brut will run your app via <a href="/api/Brut/SpecSupport/E2ETestServer.html" target="_self" rel="noopener" data-no-router><code>Brut::SpecSupport::E2ETestServer</code></a>. It will run it before the first e2e test, leave it running during the remainder of the test suite, then stop it. This means that database changes your test makes will persist across tests.</p><p>If you are using Sidekiq, Sidekiq will be set up like normal. Jobs queued will go to Redis, and those jobs will be processed by Sidekiq, just like in production. Thus, you should not assert things about specific jobs, but rather assert the effects those jobs will have. Redis is flushed between each test.</p><h3 id="test-helpers-and-configuration" tabindex="-1">Test Helpers and Configuration <a class="header-anchor" href="#test-helpers-and-configuration" aria-label="Permalink to &quot;Test Helpers and Configuration&quot;">​</a></h3><p>Inside your test, <code>t</code> is available to produce translations. You can also access all your page and handler classes, so you can (and should) use <code>.routing</code>, e.g. <code>DashboardPage.routing</code>, to generate or access routes for your app.</p><p>You can set the <code>e2e_timeout</code> metadata on any test to override the default amount of time Playwright will wait for a locator to locate an element. The default is 5 seconds.</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">RSpec</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">describe</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;Test for login&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, </span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">e2e_timeout:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> 10</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> do</span></span>
+<span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">  # ...</span></span>
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p>You can also configure behavior with environment variables:</p><table tabindex="0"><thead><tr><th>Variable</th><th>Default</th><th>Purpose</th></tr></thead><tbody><tr><td><code>E2E_TIMEOUT_MS</code></td><td>5000</td><td>Number of milliseconds Playwright will wait for a locator to appear</td></tr><tr><td><code>E2E_SLOW_MO</code></td><td>0</td><td>Number of milliseconds Playwright will pause between operations. Useful to detect race conditions</td></tr><tr><td><code>E2E_RECORD_VIDEOS</code></td><td>unset</td><td>If set, videos of each test run are saved in <code>tmp/e2e-videos</code></td></tr></tbody></table><h3 id="quirks-of-playwright" tabindex="-1">Quirks of Playwright <a class="header-anchor" href="#quirks-of-playwright" aria-label="Permalink to &quot;Quirks of Playwright&quot;">​</a></h3><p>The Playwright JavaScript API is heavily asycnhronous, requiring liberal use of <code>await</code>. The <code>playwright-ruby-client</code> wrapper abstracts that so you can write more straightfoward code.</p><p>The main thing to be aware of is that locators that fail only fail when you attempt to assert something.</p><p>For example</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">button</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> = page.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">locator</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;form button&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">) </span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># suppose this button doesn&#39;t exist</span></span>
 <span class="line"></span>
-<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">button.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">click</span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"> # This is where you&#39;ll see a failure</span></span></code></pre></div><p>This hidden asynchronous behavior also means that certain calls will wait a period of time for the element you are locating to appear. This is why the example test above works without having to explicitly wait for a page refresh. After <code>button.click</code>, presumably the back-end is contacted and the page is re-rendered with an error. As long as that happens within a second or so, the code will wait for an element matching <code>[role=&#39;alert&#39;]</code> to show up.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>E2e tests are slow. They can also be flaky if you aren&#39;t careful in how you write them and how you author your HTML.</p><h3 id="test-major-flows-not-exhaustive-branches" tabindex="-1">Test Major Flows, Not Exhaustive Branches <a class="header-anchor" href="#test-major-flows-not-exhaustive-branches" aria-label="Permalink to &quot;Test Major Flows, Not Exhaustive Branches&quot;">​</a></h3><p>E2e tests give the most value when they assert that a sequence of actions the visitor takes result in what you expect—a &quot;major flow&quot;. Testing some error cases can be useful, but you should not use e2e tests to assert every single possible thing that could happen on a page.</p><p>In fact, your app might be better off leaving some behaviors better untested instead of tested by an e2e test. Use your judgement and be aware of the carrying cost of each e2e test.</p><h3 id="use-css-selectors" tabindex="-1">Use CSS Selectors <a class="header-anchor" href="#use-css-selectors" aria-label="Permalink to &quot;Use CSS Selectors&quot;">​</a></h3><p>The main Playwright documentation encourages you to locate elements by &quot;accessible names&quot; and other indirect ways of finding elements. In practice, this is error prone and tedious. Determining the accessible name of an element is not always easy.</p><p>We recommend you assess your app&#39;s accssibility in another way than trying to do it while performing end-to-end tests. Instead, locate elements with CSS selectors—this is what you&#39;d use to debug your app so it makes sense as a testing technique.</p><p>Insulating your end-to-end tests from markup changes does not produce significant savinsg and can make tests more difficult to write.</p><h3 id="testing-must-inform-your-html" tabindex="-1">Testing Must Inform your HTML <a class="header-anchor" href="#testing-must-inform-your-html" aria-label="Permalink to &quot;Testing Must Inform your HTML&quot;">​</a></h3><p>To allow CSS selectors to survive minor changes to a page, your HTML should be authored with testing in mind. In the example above, we locate the flash by looking for <code>[role=&#39;alert&#39;]</code>, since this is the most semantically correct way to mark up a flash message that contains an error.</p><p>ARIA roles that should be applied for accessibility purposes can be leveraged as locators, as can custom elements. Remember that any custom element is valid, even if it has no associated JavaScript. Custom elements are an excellent way to &quot;tag&quot; markup for use in tests or progressively-enhanced behavior.</p><p>CSS classes, on the other hand, are not a good candidate for identifying markup in a test. CSS classes exist to afford visual styling of elements and are the most likely to change as the app evolves. A better fallback if there is no other way to locate an element is to use <code>data-testid</code>. It makes itself painfully clear why it&#39;s there. Use this sparingly, but it&#39;s there if you need it.</p><h3 id="asserting-the-lack-of-content-basically-doesn-t-work" tabindex="-1">Asserting the Lack of Content Basically Doesn&#39;t Work <a class="header-anchor" href="#asserting-the-lack-of-content-basically-doesn-t-work" aria-label="Permalink to &quot;Asserting the Lack of Content Basically Doesn&#39;t Work&quot;">​</a></h3><p>To assert that some content or an element <strong>is not</strong> on the page requires locating it and waiting the timeout for that locate to fail. This sucks. Don&#39;t do it.</p><p>If you need to assert that something did not happen, you may want to design your page or app such that markup appears that indicates whatever it is didn&#39;t happen. This is not ideal, but a web page is a living thing that never stops changing, so your test can&#39;t just assume it&#39;s all synchronous.</p><h3 id="try-to-use-the-defaults-for-timeouts" tabindex="-1">Try to Use the Defaults for Timeouts <a class="header-anchor" href="#try-to-use-the-defaults-for-timeouts" aria-label="Permalink to &quot;Try to Use the Defaults for Timeouts&quot;">​</a></h3><p>Your app should not take 5 seconds to do anythning, especially not inside a test. You may need to bump up the timeout to figure out what&#39;s going wrong, or set <code>E2E_SLOW_MO</code> to watch a video test, but once you&#39;ve sorted out the issue, restore these to their defaults.</p><p>If you <em>must</em> set <code>e2e_timeout</code> as metadata on test, <strong>explain why</strong> and try removing it every so often to make sure it&#39;s still needed.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>The test server is run bin <code>bin/test-server</code>, which is why Sidekiq will be running when your app is running for an e2e test.</p>`,48)]))}const k=s(n,[["render",o]]);export{u as __pageData,k as default};
+<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">button.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">click</span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"> # This is where you&#39;ll see a failure</span></span></code></pre></div><p>This hidden asynchronous behavior also means that certain calls will wait a period of time for the element you are locating to appear. This is why the example test above works without having to explicitly wait for a page refresh. After <code>button.click</code>, presumably the back-end is contacted and the page is re-rendered with an error. As long as that happens within a second or so, the code will wait for an element matching <code>[role=&#39;alert&#39;]</code> to show up.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>E2e tests are slow. They can also be flaky if you aren&#39;t careful in how you write them and how you author your HTML.</p><h3 id="test-major-flows-not-exhaustive-branches" tabindex="-1">Test Major Flows, Not Exhaustive Branches <a class="header-anchor" href="#test-major-flows-not-exhaustive-branches" aria-label="Permalink to &quot;Test Major Flows, Not Exhaustive Branches&quot;">​</a></h3><p>E2e tests give the most value when they assert that a sequence of actions the visitor takes result in what you expect—a &quot;major flow&quot;. Testing some error cases can be useful, but you should not use e2e tests to assert every single possible thing that could happen on a page.</p><p>In fact, your app might be better off leaving some behaviors better untested instead of tested by an e2e test. Use your judgement and be aware of the carrying cost of each e2e test.</p><h3 id="use-css-selectors" tabindex="-1">Use CSS Selectors <a class="header-anchor" href="#use-css-selectors" aria-label="Permalink to &quot;Use CSS Selectors&quot;">​</a></h3><p>The main Playwright documentation encourages you to locate elements by &quot;accessible names&quot; and other indirect ways of finding elements. In practice, this is error prone and tedious. Determining the accessible name of an element is not always easy.</p><p>We recommend you assess your app&#39;s accessibility in another way than trying to do it while performing end-to-end tests. Instead, locate elements with CSS selectors—this is what you&#39;d use to debug your app so it makes sense as a testing technique.</p><p>Insulating your end-to-end tests from markup changes does not produce significant savings and can make tests more difficult to write.</p><h3 id="testing-must-inform-your-html" tabindex="-1">Testing Must Inform your HTML <a class="header-anchor" href="#testing-must-inform-your-html" aria-label="Permalink to &quot;Testing Must Inform your HTML&quot;">​</a></h3><p>To allow CSS selectors to survive minor changes to a page, your HTML should be authored with testing in mind. In the example above, we locate the flash by looking for <code>[role=&#39;alert&#39;]</code>, since this is the most semantically correct way to mark up a flash message that contains an error.</p><p>ARIA roles that should be applied for accessibility purposes can be leveraged as locators, as can custom elements. Remember that any custom element is valid, even if it has no associated JavaScript. Custom elements are an excellent way to &quot;tag&quot; markup for use in tests or progressively-enhanced behavior.</p><p>CSS classes, on the other hand, are not a good candidate for identifying markup in a test. CSS classes exist to afford visual styling of elements and are the most likely to change as the app evolves. A better fallback if there is no other way to locate an element is to use <code>data-testid</code>. It makes itself painfully clear why it&#39;s there. Use this sparingly, but it&#39;s there if you need it.</p><h3 id="asserting-the-lack-of-content-basically-doesn-t-work" tabindex="-1">Asserting the Lack of Content Basically Doesn&#39;t Work <a class="header-anchor" href="#asserting-the-lack-of-content-basically-doesn-t-work" aria-label="Permalink to &quot;Asserting the Lack of Content Basically Doesn&#39;t Work&quot;">​</a></h3><p>To assert that some content or an element <strong>is not</strong> on the page requires locating it and waiting the timeout for that locate to fail. This sucks. Don&#39;t do it.</p><p>If you need to assert that something did not happen, you may want to design your page or app such that markup appears that indicates whatever it is didn&#39;t happen. This is not ideal, but a web page is a living thing that never stops changing, so your test can&#39;t just assume it&#39;s all synchronous.</p><h3 id="try-to-use-the-defaults-for-timeouts" tabindex="-1">Try to Use the Defaults for Timeouts <a class="header-anchor" href="#try-to-use-the-defaults-for-timeouts" aria-label="Permalink to &quot;Try to Use the Defaults for Timeouts&quot;">​</a></h3><p>Your app should not take 5 seconds to do anythning, especially not inside a test. You may need to bump up the timeout to figure out what&#39;s going wrong, or set <code>E2E_SLOW_MO</code> to watch a video test, but once you&#39;ve sorted out the issue, restore these to their defaults.</p><p>If you <em>must</em> set <code>e2e_timeout</code> as metadata on test, <strong>explain why</strong> and try removing it every so often to make sure it&#39;s still needed.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>The test server is run via <code>bin/test-server</code>.</p>`,50)]))}const u=e(n,[["render",o]]);export{k as __pageData,u as default};

data/docs/assets/end-to-end-tests.md.DzqRpZ43.lean.js

@@ -0,0 +1 @@
+import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const k=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(l,s,h,r,p,d){return a(),t("div",null,s[0]||(s[0]=[i("",50)]))}const u=e(n,[["render",o]]);export{k as __pageData,u as default};