WEB/システム/IT技術ブログ

Laravelにデフォルトで組み込まれている「PHPUnit」を使ってユニットテスト(単体テスト)を実施してみます。
今回は、Webアプリケーションに正しくアクセスできているか、HTTPテストを実施します。

公開済みのLaravelプロジェクトを対象とします。

  • Laravel 7.30.6
  • PHPUnit 8.5.31

テスト用スクリプトの用意

テスト用スクリプトは、サンプル「tests/Feature/ExampleTest.php」が用意されているので、これを複製し、例えば「HelloTest.php」として以下のファイルを作成します。

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class HelloTest extends TestCase
{
	public function testBasicTest()
	{
		$response = $this->get('/');
		$response->assertStatus(200);

		$response = $this->get('/about');
		$response->assertStatus(200);

		$response = $this->get('/contact');
		$response->assertStatus(200);
...
	}
}

このように記述する事で、例えばページ「/about」にリクエストした際に、正常にアクセスできているか、つまりステータスコード200を返しているかどうかテストする事ができます。
コンテンツリストやサイトマップなど仕様書から、全ページ分のコードを記述します。

Laravelサイト内で認証済みユーザのみにAPIを提供する方法です。

以前に、Laravelサイト内外問わず、APIで認証機能を提供するしくみとしてPassportを紹介しました。
LaravelでPassportパッケージ(OAuth2)を使用したAPI認証を構築

今回は、PassportではなくSessionを用いて、Laravelサイト内に限定し、かつ、認証済みのユーザのみにAPIを提供する方法を紹介します。
SPAではないが、パフォーマンス的に部分的にAPIで情報を提供する際に有効です。

  • PHP 7.3.33
  • Laravel 6.20.44

APIでセッション認証の有効化

まず「config/auth.php」を開き、apiのドライバをwebと同じ「session」にします。

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'session',
            'provider' => 'users',
        ],
    ],

GitHub Actionsを使ってレンタルサーバに自動でデプロイします。
これまで、GitHubで管理しているソースをコミット、プッシュした後、その差分を手動FTPでサーバにアップしてましたが、その部分を自動化したいと思います。

GitHub Actionsのドキュメント – GitHub Docs

ここでは、デプロイ対象のGitHubリポジトリとデプロイ先のレンタルサーバは、既存のものを利用します。

ワークフローファイル作成

GitHub Actionsの動作を設定するワークフローファイルを作成します。
今回は単純に、masterブランチにpushがあったら、ファイルをレンタルサーバにFTPアップロードします。

name: deploy
on:
  push:
    branches: [master]
jobs:
  web-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: get lastest code
        uses: actions/checkout@v3
      - name: sync files
        uses: SamKirkland/FTP-Deploy-Action@4.3.0
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}

「name」は任意です。「runs-on」にはデプロイ環境を指定します。
FTPにはGitHub – SamKirkland/FTP-Deploy-Actionを使用します。
FTPのユーザ名やパスワードなどをコードに書くことはセキュリティ的にリスクがあるので、環境変数を使用します。

Laravelで多次元データから任意のキーのみ取り出す方法です。

例えば、ユーザテーブルから複雑なクエリビルダで以下のデータを取得したとします。

$users = User::get_fukuzatsu();
Log::debug($users);
[
	{
		"id": 1,
		"name": "山田太郎",
		"kana": "ヤマダタロウ",
		"tel": "11122223333",
		"age": 30,
		"sex": 1,
		"mail": "taro@xxxxx"
		"postcode": "1112222",
		...
	},
	{
		"id": 2,
		"name": "山田花子",
		"kana": "ヤマダハナコ",
		"tel": "44455556666",
		"age": 25,
		"sex": 2,
		"mail": "hanako@xxxxx"
		"postcode": "4445555",
		...
	},
	...
]

このデータの電話番号など一部データを、APIで外部に展開します。ここで、以下の課題があります。

  • 全てのデータを出すにはデータ量が多い
  • プライバシーポリシー的に出せない情報がある
  • だからと言って、クエリビルダが複雑な事もあり、電話番号などキーを絞ったクエリ「get_fukuzatsu2」などを複製するのもスマートじゃない

最近、Vue.jsやReactなどを使用したSPA開発がトレンドで、API開発も需要も高まってきてます。
Laravelでは、APIに必要なルートやコントローラを簡単に生成できるしくみが用意されています。

今回はLaravelでAPIの開発を始める際の基礎をみてみます。
ちなみに、Laravel 6.xがインストール済みであることを前提とします。
また、任意の「Sample」データに対してAPIを開発するとします。

コントローラ作成

以下のコマンドで、APIに必要な関数を含んだコントローラ「app/Http/Controllers/API/SampleController.php」を作成することができます。

$ php artisan make:controller API/SampleController --api

作成されたコントローラの中身は以下のようになってます。

namespace App\Http\Controllers\API;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class SampleController extends Controller
{
	public function index()
	{
			//
	}

	public function store(Request $request)
	{
			//
	}

	public function show($id)
	{
			//
	}

	public function update(Request $request, $id)
	{
			//
	}

	public function destroy($id)
	{
			//
	}
}

Laravel×Reactの開発環境構築を構築します。

今回試した環境は以下の通りです。

  • Laravel 6.20.44
  • Node.js 14.16.1
  • React 18.1

Laravelはインストール済みの状態から解説します。

初期LaravelにReactのインストール

初期のLaravel環境に対してReactをインストール場合、laravel/uiパッケージを利用すると便利です。ターミナルから以下のコマンドを実行します。

$ php artisan ui react

または

$ php artisan preset react

Laravelの初期状態はVue.jsがプリセットとなっています。
このコマンドを実行する事で、プリセットがReactに変更され、React開発スタートに必要なファイルが追加、変更されます。
具体的には「resources/js/components/Example.js」などが追加され、「package.json」や「webpack.min.js」などの内容が変更されます。
一方で「resources/js/components/ExampleComponent.vue」などのVue.js関連の初期ファイルは削除されます。

次に「package.json」を元にReactパッケージをインストールします。

$ npm install

基本的にReactのインストールは以上です。

但し、既にLaravelの開発が進行している場合、既存ファイルが自動で変更、削除されると困という場合はこちらの方法はお勧めできません。

とうとうWindows 11デビューしました。
想像していた通り、いくつか環境構築がこれまでのようにうまくいかず。。
「この時間返して。。今後もOSが変わるたびに、この試練を突破しないといけないのかな。。経済損失ってどれぐらいだろう。。」
など考えながら作業しております。

さて、新PCのWindows 11 Homeのセットアップを終え、環境構築の作業に入ろうと思い、PowerShellを起動したら、以下のメッセージが表示されました。

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

新機能と改善のために最新の PowerShell をインストールしてください!https://aka.ms/PSWindows

Windows Updateで最新の状態とかにしてくれないんですかね。

コマンドで現在のバージョンを調べてみると5.1のようです。

PS C:\Users\username> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.22000.653
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22000.653
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PowerShellのバージョンが古いことで、いくつか実行できないコマンドもあるようです。

Windows 10で、Docker Desktopで使ってるWSL2のプロセス「Vmmem」のメモリ使用量を制限する方法です。

WSL2を使うようになってから、ローカル開発環境にアクセスするのが重く、また、その度に私のロースペックノートPCのファンがフル回転します。。
高負荷の原因はロースペックだと考えていましたが、調べてみるとプロセス「Vmmem」を制御すれば改善しそうです。

ローカル環境で作業中に、タスクマネージャーを確認してみました。

Vmmemにより、メモリが4.5GBほど消費しています。作業を続けているとメモリ使用量は増え続け、時には全体の使用率が95%を超える場面もあります。

Windows 10のプロジェクトにTypeScriptの開発環境を構築してみます。

WindowsにはNode.jsがインストール済みであることを前提とします。
WindowsでNode.js、gulp.jsをインストールして効率よい開発環境を目指す(準備編)

インストール

コマンドプロンプトを開き、npmコマンドでTypeScriptをインストールします。

> npm install -g typescript

インストール完了後、以下のコマンドでバージョンが表示されれば、インストール成功です。

> tsc -v
Version 4.6.4

tsファイルをコンパイル

任意のTypeScriptファイル「script.ts」を用意します。今回はtsファイルの中身については割愛します。
以下のコマンドを実行すると、tsファイルがコンパイルされ、ファイル「script.js」が出力されます。

> tsc script.ts

Docker ComposeでWordPress開発環境を構築します。

今回、以下の環境に構築しました。

  • Windows 10 Home
  • Docker Engine v20.10.14

開発環境の構成はWordPress、DBはMariaDB、DB参照用にphpMyAdminです。
WordPressのプラグイン、アップロード画像やテンプレートを含むフォルダ「wp-content」はgitで管理しています。
WordPressは本番環境に合わせて、ドキュメントルートからサブフォルダ「wp」に展開します。

docker-compose.ymlを用意する

WordPress開発環境構築用に以下の「docker-compose.yml」を用意します。ファイル「docker-compose.yml」はルートに配置します。

version: '3.8'

services:
  wordpress:
    image: wordpress:5.9.3
    ports:
      - 8000:80
    depends_on:
      - db
    working_dir: /var/www/html/wp
    volumes:
      - ./public_html/wp/wp-content:/var/www/html/wp/wp-content
      - ./public_html/.htaccess:/var/www/html/.htaccess
      - ./public_html/index.php:/var/www/html/index.php
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
      WORDPRESS_DB_USER: ${MYSQL_USER}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    depends_on:
      - db
    ports:
      - 8888:80
    environment:
      PMA_HOST: db
      PMA_USER: ${MYSQL_USER}
      PMA_PASSWORD: ${MYSQL_PASSWORD}

  db:
    image: mariadb:10.5
    volumes:
      - db-volume:/var/lib/mysql
    environment:
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      TZ: Asia/Tokyo

volumes:
  db-volume:

Monthly Archives