目次
はじめに
ずっと気になっていたCircleCI/CDについて、Techpitさんで教材が出たのでこれを機に学んでみました。
✅ゴール
・CircleCI/CDの理解を深める
✅環境
Windows
✅参考教材
💻Laravel × CircleCI × AWSで学ぶCI/CD
💻いまさらだけどCircleCIに入門したので分かりやすくまとめてみた
かなり細かく記載してくれている。
CI/CDとは
そもそもCI/CDの理解がないと進みませんね。この単語を知らなかった。。。
CI/CD(Continuous Integration/Continuous Delivery):継続的インティグレーション/継続的デリバリー
CI(継続的インテグレーション(※統合の意))はプッシュされるたびに自動でテストを行いマージする仕組み。
CD(継続的デリバリー)はソースコードが変更されるたびに自動で本番環境にデプロイする仕組み。
この一連の流れをCI/CDパイプラインと呼ぶ。
👉ビルド、テスト、デプロイを自動化できる。
✅CircleCIとは
Saas型のCI/CDサービスで、クラウド上のコンテナあるいはVMを実行環境として使用。
参考:いまさらだけどCircleCIに入門したので分かりやすくまとめてみた
Dockerの環境構築
今回は、以前構築したLaradockをそのまま使ってみようと思います(※コンテナの初回起動は時間がかかるため)。
✅PHPの環境構築
laradock/.envを変更
※変更前
APP_CODE_PATH_HOST=../laravel DATA_PATH_HOST=../data COMPOSE_PROJECT_NAME=laravel-sns-mysql
※変更後
APP_CODE_PATH_HOST=../laravel-ci DATA_PATH_HOST=../data-ci COMPOSE_PROJECT_NAME=laravel-sns-ci
起動
docker-compose up -d workspace php-fpm nginx postgres
サンプルアプリのクローン
git clone -b laravel-ci https://github.com/shonansurvivors/laravel-sns laravel-ci
PHPの各種パッケージをインストール
docker-compose exec workspace composer install --prefer-dist
laravel/.envの作成と編集
cp .env.example.laravel-ci .env ~~~~以下.envの内容(デフォルト) #PostgreSQL DB_CONNECTION=pgsql DB_HOST=postgres DB_PORT=5432 DB_DATABASE=larasns DB_USERNAME=default DB_PASSWORD=secret
APP_KEYの生成
docker-compose exec workspace php artisan key:generate
データベース作成とマイグレーション
docker-compose exec workspace psql -U default -h postgres default=# create database larasns; default=# \q docker-compose exec workspace php artisan migrate
✅JavaScriptの環境構築
JavaScriptの各種パッケージのインストール
docker-compose exec workspace npm ci docker-compose exec workspace npm install // もしくはこっち docker-compose exec workspace npm run dev // Vue.jsのトランスパイル
GitHubとCircleCIの設定
✅GitHubの設定
リモートリポジトリの変更
git remote -v // 確認するとクローン元のリポジトリが表示される。 git remote set-url origin https://github.com/chobi1125/laravel-ci.git
ブランチの変更
git branch >> laravel-ci git branch -m master git push -u origin master
※初回のgit pushでは-uを付けないと今後git pullを行った時に失敗する。
✅CircleCIにログインする
GitHubのリポジトリと連携する。URL
CircleCIの処理内容を定義するconfig.ymlを編集
※教材ではbuildとdeployと2つのjobを作っていく。
version: 2.1 jobs: build: docker: - image: circleci/php:7.3-node-browsers steps: - run: echo "Hello World"
※JSONで比較
{ "version": 2.1, "jobs": { "build": { "docker": [ { "image": "circleci/php:7.3-node-browsers" } ], "steps": [ { "run": "echo \"Hello World\"" } ] } } }
yamlの読み方参考(教材1-4)。
違い①キーを””で囲まない。②値も””で囲まない(文字列含む)。③インデント必須④#でコメント⑤配列を-で表す
編集後。Start Buildingをクリック。

Add Configをクリック。circle-project-setupというブランチが作られる。

Pipelinesメニューに以下が表示される。

GitHubのリポジトリを確認するとブランチが作成されているのがわかる。

Compare&pull request⇒Create pull request。以下でCircleCIのbuildジョブが成功していることが確認できる。

上記画面から更にDetailsをクリックするとCircleCIに移動してbuildジョブの詳細を確認できる。

GitHub上でMerge pull requestボタンでマージを完了する。
ローカルリポジトリにここまでの変更を反映させる。
git checkout master git pull
CircleCIで作成したconfig.ymlをローカルで確認できる。

Laravelでテストする
単体テスト(ユニットテスト)はアプリ開発で、プログラムが正常に動作しているか確認するために用いられる。通常は関数やメソッドが単位となる。
LaravelではPHP用のユニットテストプログラムであるPHPUnitがデフォルトで組み込まれている。
・記事一覧画面表示のテスト
・記事投稿画面表示機能のテスト
(未ログイン状態であれば、ログイン画面にリダイレクト/ログイン済み状態であれば、記事投稿画面が表示)
・いいねされているかを判定するメソッドのテスト
✅phpunit.xml
テストで使用する情報が記載。
テスト用のDBに関してはデフォルトでSQLiteが設定されている。
<server name="DB_CONNECTION" value="sqlite"/>
テスト実行時は.envではなくphpunit.xml記載の環境変数が優先される。
✅testsディレクトリ
テスト用のスクリプトファイルをまとめるフォルダ。
①tests/Featureディレクトリ
Feature(機能)テストは、多くのオブジェクトがそれぞれどのように関しているかや、JSONエンドポイントへ完全なHTTPリクエストを送れているか含め、コードの幅広い範囲をテストする。
②tests/Unitディレクトリ
Unitは1つのメソッドに焦点をあててテストする。
※上記2つのディレクトリははっきりと役割がわかれているわけではない。
✅テストしてみる
不要なテストを削除
. └──laravel-ci └── tests ├── Feature │ └── ExampleTest.php └── Unit └── ExampleTest.php
※罫線で変換すると上記の記号に変換できる。参考
テストの作成
docker-compose exec workspace php artisan make:test ArticleControllerTest docker-compose exec workspace php artisan make:test ArticleTest
※–unitを付けるとUnitディレクトリに作成される。
ファクトリ(Articleモデル)の作成
※database/factories/ArticleFactory.php
docker-compose exec workspace php artisan make:factory ArticleFactory --model=Article
編集※コード割愛 教材2章
実行
vendor/bin/phpunitによって、テストフレームワークであるPHPUnitを実行
docker-compose exec workspace vendor/bin/phpunit tests/Feature/ArticleControllerTest >> . 1 / 1 (100%) // 全部で1つのテストを実行。「.」はテストの数。 OK (1 test, 2 assertions) // 1テストを実行。assertはassert~~メソッドの数。 // すべてのテストを実行する。 docker-compose exec workspace vendor/bin/phpunit // --filterオプションで実行対象とするテストメソッド名を正規表現でフィルタリング docker-compose exec workspace vendor/bin/phpunit --filter=guest docker-compose exec workspace vendor/bin/phpunit --filter=auth docker-compose exec workspace vendor/bin/phpunit --filter=null docker-compose exec workspace vendor/bin/phpunit --filter=theuser
📝基本的な書き方
・ユニットテストのプログラムはTestCaseクラスを継承して作成。
・TestCaseクラスを継承したクラスでRefreshDatabaseトレイトを使用すると、データベースをリセットする
・TestCaseクラスにあるメソッドはtestで始まる名前のメソッドをテスト用のメソッドと判断してテスト時にすべて実行する。
・使用可能なアサート一覧
・factory関数を使用することで、テストに必要なモデルのインスタンスを、ファクトリというものを利用して生成
・ファクトリ内ではFakerで文章、人名や住所、メールアドレスなどをランダムに生成してくれる、テストデータを作る時に便利な PHPのライブラリを利用する。
・AAA(Arrange-Act-Assert):準備・実行・検証を意識するとテストが書きやすくなる。
LaravelのテストをCircleCIで実行
テスト開発用ブランチの作成とリモートリポジトリへの反映
git branch -a git checkout -b feature/ci_test git push -u origin feature/ci_test
.circleci/config.yamlの編集
version: 2.1 jobs: build: docker: - image: circleci/php:7.3-node-browsers steps: - checkout // GitHubからCircleCIの環境にソースコードをコピー(git clone) - run: composer install -n --prefer-dist // Composerを使用してPHP関連パッケージをインストール - run: npm ci // npmを使用してJavaScript関連パッケージをインストール - run: npm run dev // JavaScriptのトランスパイル - run: // テストを実行。上記と異なりnameやcommandを省略せずに記載 name: php test // nameは、CircleCIの画面に表示されるステップ名 command: vendor/bin/phpunit // commandには、実行するシェルのコマンドを定義
テスト用の環境変数ファイルを作成
cp .env .env.testing docker-compose exec workspace php artisan key:generate --show // showオプションで.envに反映せずにコンソールに表示 >> base64:~~~~~~ // コピーして.env.testingにペースト
PHPUnitは、Laravelインストール後のデフォルトの設定で、.env.testingというファイルが存在すると、.envの代わりに環境変数ファイルとして使用するようになっているので、こちらがCircleCIでも適用される。
変更をプッシュ。
git remote rm origin git add . git commit -m"circleci/config.ymlの編集と.env.testingの作成編集" git remote add origin https://github.com/chobi1125/laravel-ci.git git push -u origin feature/ci_test
GitHub上でプルリクしてCircleCIのbuildジョブの結果を確認。

DetailsをクリックしてCircleCIのサイト上で詳細確認。正常に動作している!!

AWSでPostgreSQLを使うのでCircleCIでもPostgreSQLを使う。教材3-6でコードは割愛
※PostgreSQLのコンテナがグレーになっているが。これはジョブの終了とともにコンテナが停止しているからで、問題ないとのこと。

CircleCIで実行したcomposer installやnpm ciの結果をキャッシュとして保存して使いまわす
.circle/config.ymlの編集
version: 2.1 jobs: build: docker: - image: circleci/php:7.3-node-browsers steps: - checkout - restore_cache: // restore_cacheで、保存されたキャッシュを復元 key: composer-v1-{{ checksum "composer.lock" }} // keyには、復元するキャッシュの名前を指定 - run: composer install -n --prefer-dist - save_cache: // save_cacheで、keyに指定した名前でキャッシュを保存 key: composer-v1-{{ checksum "composer.lock" }} // {{ checksum "composer.lock" }}という部分は、CircleCIのテンプレート機能 paths: // 保存するディレクトリ名やファイル名をpathsに指定 - vendor - run: npm ci - run: npm run dev - run: name: php test command: vendor/bin/phpunit
再度プッシュ&プルリクでDetailsをクリック。Found a cacheとなってる◎(※2回誤ってプッシュしてしまったのでSaving Cacheの方はSkippingのスクショになってしまいました。)

プルリクをマージせずに2回目のプッシュを行うと以下のようになる(特に問題なさげ)。

Detailsをクリックするとnpm iのキャッシュはないのでインストールしているのがわかる。

以下で再度実行&キャッシュで処理が早くなることを確認できる。

テスト失敗時にmasterブランチへのマージを不可にする
GitHub上の設定
Settings⇒Branches⇒Add Rule

Branch name patternで保護するブランチ名のパターンを。
ci/circleci: buildにチェックを入れるとCircleCIのbuildジョブが正常終了していることをマージ可否の条件にできる。
Include administratorsで管理者自身にもルールを適用するか決める。
テストコードを間違えてプッシュすると以下の感じでMergeが押せなくなる◎

AWSの利用する
✅IAMでAdminユーザーの作成
上記を基に作成してログインしなおし。以下のようにユーザー名が変わる。

✅SSHキーの作成
EC2⇒キーペア⇒キーペアを作成⇒ダウンロード
ダウンロードフォルダに保存した場合の確認
cd ~/Downloads ls -l laravel-ci-ec2-user.pem >> -rw-r--r-- 1 ~~~~~ 5月 23 20:27 laravel-ci-ec2-user.pem
秘密鍵を移動する
ls -la ~ // .sshディレクトリがあるか確認。 >> drwxr-xr-x 1 ~~~~ 0 5月 9 22:44 .ssh/ mv laravel-ci-ec2-user.pem ~/.ssh
移動できたか確認
cd ~/.ssh ls -l laravel-ci-ec2-user.pem
スタックの作成
テンプレートとして以下のファイルを選択。
laravel-sns-mysql-ci\laravel-ci\aws
以下を自動生成。スタック名をlaravel-ciとして次へ。オプションは未入力で次へ。スタックの作成。
- VPC
- サブネット(パブリック * 1、プライベート * 2)
- DBサブネットグループ
- ルートテーブル
- インターネットゲートウェイ
- セキュリティグループ(パブリックサーバー用 * 1、プライベートサーバー用 * 1)
- ElasticIP
- EC2(パプリックIPアドレスありで、ElasticIPをアタッチする)
どうやら失敗。。。その際はスタックを削除してやり直しとのこと。※ルートユーザーで試しているからかもしれない。。。やり直そう。

その後IAMユーザーで実施したところ成功。

EC2を確認。新しくEC2インスタンスが作成されていることがわかる。パブリックIPアドレスを控える。

セキュリティグループのインバウンドルールタブを選択すると0.0.0.0/0からのSSH接続が許可されているのがわかる。

~/.sshの権限の確認
※rwx——となっていないとSSH接続ができない。
ls -la ~ >> drwxr-xr-x 1 ~~~ 0 5月 23 20:42 .ssh/ chmod 700 ~/.ssh // rwxになっていなかった場合 ls -l ~/.ssh // 自身のPC権限の確認 -rw-r--r-- 1 ~~~~ 5月 23 20:27 laravel-ci-ec2-user.pem // SSHに使用する秘密鍵の権限は、rw-------である必要がある chmod 600 ~/.ssh/laravel-ci-ec2-user.pem // 権限変更
※rwx—- となっていればOK。rは読み取りwは書き込みxは実行権限があることを示している。
最初の3桁は、このファイルやディレクトリの所有者に許可している権限 ここではrwx
4桁目から6桁目は、このファイルやディレクトリが属するグループに許可している権限 ここではr-x
7桁目から9桁目は、このファイルやディレクトリの所有者でもグループでも無いユーザーに許可している権限 ここではr-x
※700は、rwx——を数字で表したもの。
rは4、wは2、xは1。rwxは4 + 2 + 1で7。755であれば、rwxr-xr-xとなる。
SSHログイン
ssh ec2-user@EC2のパブリックIPアドレス -i ~/.ssh/laravel-ci-ec2-user.pem >>Are you sure you want to continue connecting (yes/no/[fingerprint])? yes __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 1 package(s) needed for security, out of 16 available Run "sudo yum update" to apply all updates. [ec2-user@~~~~]$
パッケージ管理システムのyumのリポジトリを最新化
sudo yum update -y
nginxのインストール
sudo amazon-linux-extras install nginx1.12 -y
nginxの起動※メッセージは何もなし
sudo systemctl start nginx
IPアドレスにアクセス

PHPのインストール
sudo amazon-linux-extras install php7.3 -y
Hello Worldを表示する
※nginxはusr/share/nginx/htmlディレクトリを表示する。
sudo vi /usr/share/nginx/html/index.php
起動中のプロセスを確認
※php-fpmが起動していないことがわかる
[ec2-user@ip-~~~~ ~]$ ps -o user,group,cmd -e | grep -v grep | grep -e nginx -e php-fpm >> root root nginx: master process /usr/sbin/nginx nginx nginx nginx: worker process
PHP-FPMを起動
※nginxを使ってPHPを動かすためには、PHP-FPM(FastCGI Process Manager)というプログラムが起動している必要
※PHP-FPMのプールのユーザーとグループがapacheになっている
sudo systemctl start php-fpm sudo systemctl restart nginx // nginxを再起動してphp-fpmを認識させる。 ps -o user,group,cmd -e | grep -v grep | grep -e nginx -e php-fpm // 再確認 >> root root php-fpm: master process (/etc/php-fpm.conf) apache apache php-fpm: pool www apache apache php-fpm: pool www apache apache php-fpm: pool www apache apache php-fpm: pool www apache apache php-fpm: pool www root root nginx: master process /usr/sbin/nginx nginx nginx nginx: worker process
確認

✅webappユーザーの作成 参考教材4-7
home/webappの権限を755にする
sudo vi /etc/login.defs >> UMASK 022 // 077から変更
ユーザーを追加
sudo useradd webapp
webappユーザーの権限確認
id webapp >> uid=1001(webapp) gid=1001(webapp) groups=1001(webapp) ls -l /home drwxr-xr-x 2 webapp webapp 62 May 24 01:23 webapp
Gitのインストール
sudo yum install git -y
ユーザーの切り替え
※- を付けることでそのユーザーのホームディレクトリへ移動
sudo su - webapp
サンプルアプリケーションのインストール
git clone https://github.com/chobi1125/laravel-ci.git laravel-ci // home/webappで実行
Composerのインストール
exit // ec2-userに変更 sudo curl -sS https://getcomposer.org/installer | php // home/ec2-userで実行 sudo chown root:root composer.phar sudo mv composer.phar /usr/bin/composer composer -V //コマンド確認 >> Composer version 1.10.6 2020-05-06 10:28:10
php-mbstringとphp-xmlのインストール
※これがないとLaravel(PHP関連パッケージ)のインストールが失敗する
sudo yum install php-mbstring php-xml -y
PHP関連パッケージのインストール
sudo su - webapp cd laravel-ci composer install --no-dev --prefer-dist
※–no-devオプションで、開発時のみ必要で、本番環境で必要ではないパッケージ(composer.jsonのrequire-dev記載のパッケージ)をインストールしないようにする。本番環境ではこのオプション付けが一般的。
.envの作成
cp .env.example.laravel-ci .env ls -la .env // 確認 >> -rw-rw-r-- 1 webapp webapp 1160 Apr 29 15:43 .env php artisan key:generate
.envの編集
vi .env ~~~~ APP_NAME=Laravel APP_ENV=production #==========この行を変更(localをproductionに変更) APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= APP_DEBUG=false #==========この行を変更(trueをfalseに変更) APP_URL=http://xxx.xxx.xxx.xxx #==========この行を変更(localhostをEC2のパブリックIPアドレスに変更) # 略</pre> <strong>✅JavaScript関連のビルド <a href="https://www.techpit.jp/courses/917488/lectures/17204938">教材4-10</a></strong> Node.jsのインストール <pre class="ql-syntax" spellcheck="false">exit// ec2-userに切替 curl -sL https://rpm.nodesource.com/setup_13.x | sudo bash - sudo yum install -y nodejs</pre> gcc-c++のインストール ※npm run prodを成功させるため <pre class="ql-syntax" spellcheck="false">sudo yum -y install gcc-c++</pre> アプリの関連パッケージのインストール <pre class="ql-syntax" spellcheck="false">sudo su - webapp cd laravel-ci npm ci npm run prod // トランスパイル</pre> <strong>✅nginxの設定変更</strong> <pre class="ql-syntax" spellcheck="false">exit sudo vi /etc/nginx/nginx.conf</pre> ※変更内容は割愛。<a href="https://www.techpit.jp/courses/917488/lectures/17204948">参考</a> ※フォルダ階層 <pre class="ql-syntax" spellcheck="false">. └──etc ├── nginx │ ├── conf.d │ │ └── php-fpm.conf │ ├── default.d │ │ └── php.conf │ └── nginx.conf // このファイル └── php-fpm.d └── www.conf</pre> <strong>✅PHP-FPMの設定変更</strong> ※サンプルアプリケーションのインストール先に合わせて権限を変更 <pre class="ql-syntax" spellcheck="false">sudo vi /etc/php-fpm.d/www.conf ~~~~ ; RPM: apache user chosen to provide access to the same directories as httpd user = webapp ;=============この行を変更(apacheをwebappに変更) ; RPM: Keep a group allowed to write in log dir. group = webapp ;=============この行を変更(apacheをwebappに変更)
再起動
sudo systemctl restart php-fpm ps -o user,group,cmd -e | grep -v grep | grep php-fpm >> php-fmp wwwの行のユーザーとグループがwebappになっていればOK
nginxも再起動
sudo systemctl restart nginx
IP/loginにアクセス(DB設定しなくても表示できる画面のため)

RDSの作成
RDSにアクセス
⇒データベースの作成
⇒標準作成、PostgreSQL(バージョン11.6-R1)、無料利用枠
⇒設定



データベースの作成⇒認証情報の詳細を表示⇒マスターパスワードとエンドポイントを確認する。

.envの編集
sudo su - webapp vi laravel-ci/.env ~~~~ #PostgreSQL DB_CONNECTION=pgsql DB_HOST=laravel-ci.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com #==========この行を変更(postgresからRDSのエンドポイントに変更) DB_PORT=5432 DB_DATABASE=larasns DB_USERNAME=postgres #==========この行を変更(defaultからRDSのマスターユーザー名に変更) DB_PASSWORD=XXXXXXXXXXXXXXXXXXXX #==========この行を変更(secretからRDSのマスターパスワードに変更)</pre> .envの権限変更 ※最後のr--が他のユーザーに許可された権限であり、r(読み取り権限)が許可されているので読み取りできないように変更。 <pre class="ql-syntax" spellcheck="false">ls -l laravel-ci/.env >> -rw-rw-r-- 1 webapp webapp 1283 Apr 30 15:57 laravel-ci/.env chmod 660 laravel-ci/.env ls -l laravel-ci/.env >> -rw-rw---- 1 webapp webapp 1282 May 24 02:22 laravel-ci/.env</pre> <strong>✅pgsqlのインストール</strong> <pre class="ql-syntax" spellcheck="false">exit sudo yum install php-pgsql.x86_64 -y sudo systemctl restart php-fpm // 再起動</pre> マイグレーション ※本番環境だと確認が求められる <pre class="ql-syntax" spellcheck="false">sudo su - webapp cd laravel-ci [webapp@~~~~ laravel-ci]$ php artisan migrate ************************************** * Application In Production! * ************************************** Do you really wish to run this command? (yes/no) [no]: > yes Migration table created successfully. Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table (0.02 seconds) Migrating: 2014_10_12_100000_create_password_resets_table Migrated: 2014_10_12_100000_create_password_resets_table (0.01 seconds) Migrating: 2019_08_19_000000_create_failed_jobs_table Migrated: 2019_08_19_000000_create_failed_jobs_table (0.01 seconds) Migrating: 2020_01_23_221657_create_articles_table Migrated: 2020_01_23_221657_create_articles_table (0.01 seconds) Migrating: 2020_02_14_212406_create_likes_table Migrated: 2020_02_14_212406_create_likes_table (0.01 seconds) Migrating: 2020_02_16_205740_create_tags_table Migrated: 2020_02_16_205740_create_tags_table (0.01 seconds) Migrating: 2020_02_16_205945_create_article_tag_table Migrated: 2020_02_16_205945_create_article_tag_table (0.01 seconds) Migrating: 2020_02_18_100555_create_follows_table Migrated: 2020_02_18_100555_create_follows_table (0.01 seconds)
動作確認

✅psqlのクライアントツールを利用可能にする
インストール
sudo yum install postgresql.x86_64 -y
以下でログイン可能
psql -h RDSのエンドポイント -U データベースのユーザー名 -d データベース名
おわりに
この教材を通じてどんどんテストコードに慣れていきたい。
もう少し書こうかと思ったけど記事が長くなりすぎているので分けます。
以下続き。
活用中のリポジトリは以下。
以下、今後やっていきたいなと思ったこと
①Laravelでテストコード作成⇒phpunitテスト実行&確認に慣れる。
②GitHub&CircleCIの連携になれる。
③AWSの体系的な理解。EC2にSSH接続&鍵の生成
RDS、S3(デプロイのログ.zip形式)、AWS CLIの利用。
④シェルスクリプトの理解
※転職活動時リポジトリ公開でテストコードがないとデバッグできていないと判断される。
⑤nginx、php-fpmの理解(Dockerでも使う)
備忘録
💻IAM とは
AWSは普段からrootユーザーを使わずにIAMで安全に制御されたユーザーを使うことを推奨しているらしい。
💻あなたがnpm installをしてはいけない時 – Qiita
とても参考になる。npm iで各々の環境にずれが生じる可能性がある。
💻初心者向けシェルスクリプトの基本コマンドの紹介
シェルスクリプトとは、簡単に言うとUnixコマンドなどを並んで実行するだけ
💻【入門者向け】シェルスクリプトの作成・実行方法をわかりやすく解説!
シェルスクリプトは、シェルによって解釈・実行される一連の処理を記述したスクリプト
「シェル」とは、ユーザーからの操作を受け付け、操作通りに動作した結果を出力するプログラムです。
💻単体テスト(ユニットテスト)とは
単体テスト(ユニットテストと呼ばれることもあります)は、プログラムを構成する比較的小さな単位(ユニット)が個々の機能を正しく果たしているかどうかを検証するテストです。通常、関数やメソッドが単体テストの単位(ユニット)となります。
コメントを残す