---
# System prepended metadata

title: Untitled

---

### pre-mainを作って、本番環境デプロイ前にreleaseブランチをE2Eテスト→デプロイ後にE2E

メモ
stg→pre-main(E2E)→main(E2E)


Estimate・・・3

- 本当の本番環境のテストではないので、今回の環境変数の違いによる不具合は検知できない

#### メリット
- 事前テストができる。不具合検知までの時間は減る

#### デメリット
- 本当の本番環境のテストではないので、今回の環境変数の違いによる不具合は検知できない
    - 環境変数についてはherokuの機能で特定ファイルを作れば統一は可能
    - デプロイのチェックリストを作成し、環境変数にタイポなどがないかの厳格な確認も整備予定

#### 手法
redirect-on-rails.herokuapp.comにスクレイピングしてE2Eテストするスクリプトを作成する
https://www.dkrk-blog.net/javascript/puppeteer01
1. ブラウザを開く
2. class指定などでボタンをクリック
3. キャンペーン詳細画面、文面コピーを押すまでの動作　一通り一行
4. 表示してあるURLを正規表現でコピー？
```js
const puppeteer = require('puppeteer')
(async () => {
  const browser = await puppeteer.launch()
  const page = await browser.newPage()
　　　// urlを開き、DOMContentLoadedまで待つ
  await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded'
  })
  // ここに処理を書いていく
  await browser.close()
})()
```

### 本番環境デプロイ後、即スクレイピングなどでE2Eテストを走らせる
Estimate・・・3

#### メリット
- 本番環境のテストが可能

#### デメリット
- デプロイ→テスト終了までテスト対象の動作が保証されない


### 本番では、リダイレクト機能だけ手動でテストするのもアり
前提：releaseでのE2Eはやる
Estimate・・・3

#### メリット
- releaseでE2Eができつつ、一番重要なリダイレクト機能については本番での動作を確認できる

#### デメリット
- デプロイ→テスト終了までテスト対象の動作が本番では保証されていない
