Phalcon フレームワークに PHPUnit を組み込む手順まとめ【実践メモ】

Webアプリケーションの品質を保つうえでユニットテストは欠かせません。
今回は、Phalcon フレームワークを使ったシステム保守の現場で、PHPUnit を導入した際の手順をまとめました。

各バージョンは以下の通りです。
・Phalcon 3.4.5
・PHP 7.2.34
・PHPUnit 8.5

1. PHPUnitを開発依存パッケージとしてインストール

composer で PHPUnit を追加します。
ローカル開発環境で使用するため、”–dev” オプションを付けてインストールします。

[crayon-694dd37f0dbc6816532166  ]composer require --dev phpunit/phpunit

1	[crayon-694dd37f0dbc6816532166 ]composer require --dev phpunit/phpunit

[/crayon]

2. composer.json へオートローダを設定

composer.json ファイルへテスト用クラスの自動読み込み設定を追加します。
PSR-4 に準拠して、”tests/” ディレクトリ以下のクラスを “Tests\” の名前空間で扱います。

[crayon-694dd37f0dbcb979239430  ]※composer.jsonの一部抜粋

"require-dev": {
    "phpunit/phpunit": "^8.5"
},
"autoload-dev": {
    "psr-4": {
        "Tests\\": "tests/"
    }
}

[crayon-694dd37f0dbcb979239430 ]※composer.jsonの一部抜粋

"require-dev": {

"phpunit/phpunit": "^8.5"

"autoload-dev": {

"psr-4": {

"Tests\\": "tests/"

}

[/crayon]

3. Phalcon Incubator の導入

Phalcon にはユニットテスト用の抽象クラスなどが用意された公式パッケージ “phalcon/incubator” があるため、それを導入します。

[crayon-694dd37f0dbcf175062655  ]composer require --dev phalcon/incubator

1	[crayon-694dd37f0dbcf175062655 ]composer require --dev phalcon/incubator

[/crayon]

4. Composer インストール

各依存ライブラリをインストールします。
フレームワークのバージョンに応じて依存ライブラリを変更せずに再構築したいため、次のコマンドでインストールを行います。

※ “composer update” はライブラリのバージョンが変わる可能性があるため、依存関係を崩さず、今回導入するもののみインストールします。

[crayon-694dd37f0dbd3272888501  ]composer install

1	[crayon-694dd37f0dbd3272888501 ]composer install

[/crayon]

5. オートロードを再構成

テストクラスを新しく追加した場合や “composer.json” を変更した際は、オートロードを再生成します。

[crayon-694dd37f0dbd6777187993  ]composer dump-autoload -o

1	[crayon-694dd37f0dbd6777187993 ]composer dump-autoload -o

[/crayon]

私の場合、ここでエラーが出ました。

Error: Class 'App\Support\○○○\△△△' not found

1	Error: Class 'App\Support\○○○\△△△' not found

エラーが出ると身構えますが、classが見つからないというエラーでした。
よくよく確認すると同じclassではあるものの、記述されるファイルによってディレクトリ名やクラス名のキャメルケースが揃っていないということがわかりました。
バージョンが古いため、今までは問題なく動いていたようですが、これを機に見直し修正しました。
その後は無事問題なくオートロードの再編成ができました。

6. テストの実行

準備が整ったら、実際にテストを実行します。
導入段階では “SampleTest.php” を作成し、”SUCCESS” と出力する簡単なテストを作成しました。

[crayon-694dd37f0dbdc213452335  ]vendor/bin/phpunit tests/SampleTest.php

1	[crayon-694dd37f0dbdc213452335 ]vendor/bin/phpunit tests/SampleTest.php

[/crayon]

ひと通り行った手順は以上となります。
上記テスト実行でも “SUCCESS” と帰ってきたのでホッとしました。

まとめ

初めての案件で Phalcon を触ったこともあり、苦戦しました。
Laravel も研修で少し触った程度の知識しかなかったため、理解が追いつかない部分も多かったです。
作業中はネットの記事を参考に進めました。
Phalcon を扱っている情報は、ある程度経験を積んだエンジニア向けに書かれているものが多い印象でした。
コマンドだけがさらっと書かれており、コマンドや設定の説明が少なく、自分のレベル感だと読み解くのに時間がかかりました。
また記事はPHPUnit単体の話が多く、フレームワークと組み合わせた話があまりありませんでした。
テスト導入を実際にやってみたところ、出てきたコマンドを一つずつ調べ、そのコマンドが何をしているのか、どのファイルにどう影響するのかを追いかけるところを並行する必要がありました。
エラーメッセージを頼りに原因を切り分けていく作業は大変でしたが、その分、フレームワークやツールの挙動を理解するきっかけにもなったかなと感じています。

新入社員ブログ　斎藤06[PHPUnitデータプロバイダ]

25年度入社の斎藤です。

　以前、斎藤04[PHPUnitについて]のブログでは、以下のようにテスト対象のクラスメソッドに対して、1つのデータだけを使って、メソッドの動作を検証しました。

※addメソッドに対して、引数(2,3)の場合のみ検証

しかし、上記の結果で得られる検証結果は引数が(2,3)の場合は正常に機能するということしか保証できません。
実際のテストでは様々な入力を用いて多角的に検証していく必要があります。PHPUnitにはそのための便利な機能として、データプロバイダ(DataProvider)があります。今回は、そのデータプロバイダの使い方について簡単に説明していきます。

データプロバイダの作成・紐づけ

　今回は斎藤04[PHPUnitについて]のブログですでに作成したテストコード(Sample_Test.php)を流用し、これにコードを追記することでデータプロバイダを利用することにします。
データプロバイダによるテストの対象はaddメソッドとします。

Sample_Test.php(以前のブログで作成済み)

1.データプロバイダの参照を追加
まず、データプロバイダがテストコード内で利用できるように以下の参照をテストコードに追加します。

2.テストメソッドを引数をとるカタチに修正
前回はテストメソッド(test_add)内で、テスト対象のメソッドであるaddメソッドを呼び出し、その引数にデータ(2,3)を直接記述しました。

以前のテストメソッド(test_add)

今回は、このテストメソッドを以下のように修正することで、任意の入力でaddメソッドを検証できるようにします。

修正1: addメソッドの引数を変数に変更する
add(2,3) → add($var1,$var2)

修正2: アサーションメソッドの期待出力値を変数に変更する
assertEquals(5,$result) → assertEquals($expected,$result)

修正3: テストメソッドがこれらの変数を引数として受け取れるようにする
test_add() → test_add($var1,$var2,$expected)

これらの修正を加えるとテストメソッド(test_add)は以下のようになります

3.データプロバイダを作成する
データプロバイダはテストメソッドの引数に合わせるように作成していきます。データプロバイダはメソッドとして作成することができ、テストメソッドの直下に記述します。以下の例(SampleDataProvider)にあるように、データの組み合わせによってパターン名を付けることをができます。このパターン名はテスト実行時に表示されるので、どのパターンの認証が成功し、失敗したのか一目で分かります。

データプロバイダの例(SampleDataProvider)

今回のテストメソッド(test_add)は

第１引数($var1): 任意の整数
第２引数($var2): 任意の整数
第３引数($expected): $var1と$var2の合計

よって、データプロバイダに用いるデータの組み合わせは以下のようなものが考えられます。
[任意の整数,任意の整数,２つの整数の合計値]
= [1,1,2][2,2,4][0,0,0][-1,-2,-3]…..etc

今回はデータプロバイダを以下のように定義します。
メソッド名: additionDataProvider

4.テストメソッドとデータプロバイダを紐づける
テストメソッド(test_add)の１行上にピッタリと乗せるように、以下の記述を追加します。これによってテストメソッドとデータプロバイダが紐づけられます。

以上で、データプロバイダの追加は完了です。テストコード全体は以下のようになります。

以下のテストコマンドを実行します。

これで、データプロバイダで作成した3つのパターンのaddメソッドの検証と1つのパターンのsubメソッドの検証が行われ、全ての検証が正常に終了したことが分かります。

最後に

　データプロバイダを使えば、テストメソッドを検証のパターンごとに何個も記述せずに済むため、テストコードがかなりスッキリしてとても便利であると感じました。特に境界値テストなど、似たようなテストを複数実行したい場合に重宝すると思います。

以上で今回のお話をおわります。
ありがとうございました。

新入社員ブログ　斎藤04[PHPUnitについて]

25年度入社の斎藤です。

　クラスやメソッド単位での動作を保証するために行う、単体テストというものがあります。今回は、テストコードを記述することで単体テストを自動化する機能をもつPHPUnitについて、Laravelのwebアプリケーションへの導入方法と使い方を簡単に説明しようと思います。

PHPUnitの導入方法

　Laravelを導入している場合、phpunitは標準でインストールされているため、特にインストール操作は必要ありません。

テストコードの作成

　PHPUnitでの単体テストは、テスト対象となるクラスとテストコードを1対1の関係で作成していきます。

Laravelプロジェクトフォルダ内で以下のコマンドを打つことで tests/units 配下に単体テストファイル(Sample_Test)を作成できます。

作成できたテストファイル tests/unit/Sample_Test.php　にて以下のコード変更を行います。

※テストフォルダには、単体テストファイル用フォルダのtests/unit、結合テスト用のフォルダのtests/featureが存在します。unitフォルダ内に作成されるテストファイルは、厳密な単体テスト用のファイルとして作成されるため、デフォルトではLaravelが提供する外部依存機能機能(トランザクション、ファクトリー、シーダー、ファサード認証など)が使えません。しかし、実用的には単体テストにおいても、これらのLaravelの機能を含めた単体テストを行うことがあるので、上記のコードの変更を行いました。

結果、以下のようなテストコード(Sample_Test.php)のひな型が作成できます。

Sample_Test.php

次にテスト対象として、足し算、引き算の機能を持つクラス(SampleClass.php)を作成します。

SampleClass.php

これで、テスト対象となるクラス(SampleClass.php)とテストコード(Sample_Test.php)のひな型を1対1で用意できました。最後に、テストコードを編集して、テスト対象のクラスをテストできるようにします。

テストコードファイル内で追記する主な内容は

1.テストクラス内に、テスト対象のクラスのオブジェクトを定義する
　テストクラスの中で使用するテスト対象のオブジェクトを、プロパティ(変数)として宣言します。

2.setUp関数を定義する
各テストメソッドが実行される前に毎回自動で呼ばれる特別なメソッドです。
ここでテスト対象のオブジェクトを作成します。
こうすることで、テストメソッドごとに毎回新しい状態のオブジェクトを使えるようになり、テスト同士が影響し合うのを防げます。
parent::setUp()は初期化処理を継承するために必須の記述です。

3.テスト対象のメソッドごとにテストメソッドを作成する(テストメソッド名は test….)
基本的に、テスト対象のメソッド1つに対して、テストメソッドも1つ作成します。
テストメソッドごとに、テスト対象の各メソッドをテストしていくイメージです。
実際のテスト内容をここに記述します。
テストメソッド名はテスト対象のメソッド名と対応させると分かりやすいです。

4.テストメソッド内で、テスト対象クラスのオブジェクトからメソッドを呼び出し実行する
setUpメソッドで作成したテスト対象のオブジェクトを使って、実際にテストしたいメソッドを呼び出します。

5.メソッドを呼び出した後、期待する結果を検証していく(assertion)
期待する結果と実際の結果が一致しているかを検証する手段として、assertion(アサーション)が用意されています。
具体例として
・予測値と実際の結果を比較するメソッド : assertEquals()
・trueかどうかを検証するメソッド : assertTrue()
・配列の数を検証するメソッド : assertCount()
などがあります。
これをテストメソッド内で利用していきます。

これら1~5の内容をテストコード(Sample_Test.php)に追加すると以下のようになります。

あとはテストコードを実行するだけでテストを行えます。
テスト実行コマンドは以下の通りです。

作成した全てのテストファイルを実行する場合

特定のテストファイルを実行する場合

テストコードを実行すると以下のような結果が得られます。
今回の二つのメソッド(add、sub)は想定通りに機能していることが確認できました。

最後に

　PHPUnitを学んで率直に感じたことは、テストコードを記述していくことはかなり労力がかかる作業であるということです。テスト対象のコードとテストコードを対にして記述していく必要があるため、単純計算で2倍程度のコードを記述することになります。小規模なシステムや修正があまり発生しないコードでは、この労力は割に合わないかもしれません。しかし、システムが大規模になり、複数人での開発や頻繁な変更が発生する環境では、自動テストによって迅速に品質を保証し続けられるメリットは大きいものなのだろうと思いました。

以上で今回の話をおわります。
ありがとうございました。

テストの基本の”き”をおさえよう！

’23年度入社の紙屋です！
本年度は単体テストに対して理解を深め、成果物のクオリティを担保するという点を目標の一つとして業務に取り組んでまいりました。
リリース前にテストを行い、早期に不具合を発見することもできましたが、テスト内容の不十分さや検証環境へリリース後、お客様からのご指摘で不具合を発見するなどの反省点もありました。
テストを行うための心構えとして備忘録的にまとめようと思います！

テストの目的と重要性

バグの早期発見と修正が可能
プログラマーの心理的安全性を保つ
機能改修時の予期せぬエラーを防ぐ
コードの挙動理解を助ける

テストの考え方

FeatureとUnitに分けて管理することが多い
* Feature（機能）テスト：
ユーザー目線のテストです。
より大きい範囲で行い、アプリケーションに求められる機能を確認します。
* Unit（単体）テスト：
プログラマ目線のテストです。
より小さい範囲で行い、各パーツごとにエラーがないかを確認します。
ブラックボックステスト、ホワイトボックステストの目的を意識する
* ブラックボックステスト：
システムの外部から機能や仕様を検証します。
システムが仕様通りに動作するか、画面レイアウトや使いやすさを評価することに重点を置きます。
* ホワイトボックステスト：
内部のコード構造や処理フローを検証します。
内部ロジックのの正確性を評価します。

テストの作成

テストの作成から実行方法までLaravelを使用した方法でまとめようと思います。

テスト作成のコマンド：

php artisan make:test XxxxTest

1

php artisan make:test XxxxTest

上記コマンドはFeatureテストとして作成されます。
もしもUnitテストとして作る際は、オプションを付けましょう。

php artisan make:test XxxxTest --unit

1

php artisan make:test XxxxTest --unit

* ファイル名は通常 ‘XxxxTest.php’ の形式を指定します。

テストケース名には必ず「test」と入れ、「test***」とテスト名と条件なども記載します。

テストコードの構造

テストコードは以下のような形をとります。

class ExampleTest extends TestCase
{
    protected function setUp(): void
    {
        // テスト前の準備
        parent::setUp();
    }

    protected function tearDown(): void
    {
        // テスト後のクリーンアップ
        parent::tearDown();
    }

    public function testExample()
    {
        // テストケース
        $this->assertTrue(true);
    }
}

class ExampleTest extends TestCase

{

protected function setUp(): void

{

// テスト前の準備

parent::setUp();

}

protected function tearDown(): void

{

// テスト後のクリーンアップ

parent::tearDown();

}

public function testExample()

{

// テストケース

$this->assertTrue(true);

}

setUp や tearDown はテストケースの事前・事後処理を行います。
* setUp：事前処理（変数の初期化やデータの準備など）
* tearDown：事後処理（不要なデータの削除など）
* setUpやtearDownを書く際は、メソッドの戻りと指定 ‘: void’ も忘れずに書くことが必要です。

アサーションについて

プログラミングのデバッグやテストのために用いられる方法の1つです。
以下のような働きをします。

テスト結果を即座に確認できる
テストが意図した通りに動作したかを検証できる
テスト条件が妥当なデータかを判断できる
テストが失敗した要因を特定しやすい

アサーションメソッドは主に以下のようなものがあります。

assertTrue：実測値がtrueであることを期待
assertFalse：実測値がfalseであることを期待
assertEquals：実測値と予測値が一致することを期待
assertSame：実測値と予測値が型も含めて一致することを期待
assertEmpty：中身が空であることを期待
assertNotEmpty：中身が空でないことを期待
assetStatus：アクセス結果のステータスコードを確認
assertRedirest：アクセス後、どこにリダイレクトされるかを確認
assertSee：レスポンス内に特定の文字列が存在することを確認

テストの実行方法

全てのテストを実行する場合

php artisan test

1

php artisan test
フォルダを指定してテストを実行する場合（例：フォルダ名tests/Feature）

php artisan test tests/Feature

1

php artisan test tests/Feature
ファイルを指定してテストを実行する場合（例：ファイル名ExampleTest.php）

php artisan test tests/Feature/ExampleTest.php

1

php artisan test tests/Feature/ExampleTest.php
メソッド名を指定してテストを実行する場合（例：メソッド名testExample）

php artisan test --filter testExample tests/Feature/ExampleTest.php

1

php artisan test --filter testExample tests/Feature/ExampleTest.php

テストコード作成のポイント

テストメソッドは簡潔に保つ
呼ばれるアサーションを条件分岐してしまうと、一貫したテスト結果が得られなくなる可能性があります。結果が数パターンある場合は、愚直にそのパターン数分テストを準備する必要があります。
必ず通るテストを書く（時間依存や確率的要素を避ける）
ダミーデータは実際の内容に近い内容にする
データはより正確な方が本番環境に近い挙動のテストを行うことができます。
テスト対象となるロジックはシンプルにする
複雑な条件になりそうな場合はメソッド化して対応します。そのほうがテストケースも少なくて済むことがあります。
ロジックはネスト構造を複数持たないよう心掛け、アーリーリターンを設けるなど対応します。
３つのAを意識する
〇 Arrange（準備）：テストを行うにあたっての必要な準備段階のこと
〇 Act（実行）：準備したデータを元にアクションを起こすこと
〇 Assert（検証）：アクション後に期待する結果になっているか検証すること
上記3つのAを意識してテストを行います。

以上がテストについての基本になります。
単体テストを適切に実施することで、コードの品質向上とメンテナンス性の改善につながります。
なかなか時間が十分にとれず、また、多数存在する条件の洗い出しもできないとシステムの品質を担保することは難しいです。
先日参加したPHPカンファレンスでもテストの重要性に触れ、テストを書く習慣をつけ、継続して改善、向上していくように意識するようになりました。
開発に時間がかかりがちですが、テストの時間も十分に設け、自分へのフィードバックも兼ねて今後も取り組んでいきたいと思います。
日々の取り組みを重ね、また理解が進んだ段階でアウトプットできればと思います！

Linux学習についてのまとめ 02 GNU/Linux

こんにちは。22年度入社の中島です。

現在、私はLinuCの101試験に合格するためにLinuxの学習を進めています。特にGNUに関する内容を理解することが重要であると感じ、これらの知識をブログとしてまとめました。この記事を通じて、GNU/Linuxの基本的な歴史やリチャード・ストールマンの貢献、さらにはLinuxのテキストフィルタコマンドについて共有します。

1. GNUの歴史について

GNUは「GNU’s Not Unix!」の略で、Unix互換のオペレーティングシステムを開発するために1983年にリチャード・ストールマンによって開始されたプロジェクトです。当時、ほとんどのソフトウェアがプロプライエタリ（専用）であり、ソースコードが公開されていませんでした。ストールマンは、ソフトウェアの自由な使用、改変、再配布を可能にすることを目指してGNUプロジェクトを立ち上げました。

GNUプロジェクトの最も重要な成果の一つは、GPL（GNU General Public License）です。GPLは、フリーソフトウェアに特化したライセンスであり、ユーザーにソフトウェアの自由を保障します。このライセンスは、ソフトウェアを自由に使用し、改変し、再配布することを許可しますが、改変や再配布されたソフトウェアも同様にGPLの下で公開される必要があります。この仕組みを「コピーレフト」と呼びます。コピーレフトは、ソフトウェアの自由を保護するための強力な手段であり、オープンソースソフトウェアの普及に大きく寄与しました。

コピーレフトの理念は、ソフトウェアが自由であるべきという考え方に基づいており、ユーザーがソフトウェアを制限なく利用できるようにすることを目的としています。このため、GPLはフリーソフトウェア運動の基盤となり、オープンソースコミュニティにも大きな影響を与えました。

GNUプロジェクトは、Unixと同様の機能を持つ多くのソフトウェアを開発しました。これらのソフトウェアには、コンパイラ（GCC）、テキストエディタ（Emacs）、シェル（Bash）などが含まれます。これらのツールは、現在も多くのユーザーに利用され、Linuxを含むさまざまなオペレーティングシステムで使用されています。

2. リチャード・ストールマンについて

リチャード・ストールマンは、フリーソフトウェア運動の先駆者であり、GNUプロジェクトの創始者です。1985年にフリーソフトウェア財団を設立し、ソフトウェアの自由を擁護する活動を続けています。彼の主張は、ソフトウェアがユーザーに自由を与えるべきであり、そのためにはソースコードが自由にアクセスできる状態でなければならないというものです。ストールマンの理念は、多くのフリーソフトウェアのライセンス（例：GPL）に反映されており、今日のオープンソースコミュニティに大きな影響を与えています。

3. GNUから生まれたLinux

GNUプロジェクトは多くのツールを開発しましたが、オペレーティングシステムの核となるカーネルは開発されていませんでした。1991年、リーナス・トーバルズによってLinuxカーネルが発表されました。GNUツールとLinuxカーネルを組み合わせることで、現在の多くのGNU/Linuxシステムが形成されました。このように、LinuxはGNUプロジェクトと密接に関連していますが、GNUそのものとは別の存在です。

4. GNU/Linuxのテキストフィルタコマンド

GNUシステムの基本コンポーネントには、GCC（コンパイラ）、glibc（ライブラリ）、Coreutils（コマンド）、GDB（GNUデバッガ)、Bashシェルなどが含まれています。
Coreutils（GNU Core Utilities）の中でも特徴的なのが、テキストデータを加工するコマンド群になります。シェル上でこれらのコマンドを組み合わせることで強力なデータ処理が可能です。

これらのテキストフィルタコマンドは、データ処理や分析において非常に役立つツールであり、試験勉強の一環として理解を深めることで、実際の業務でも役に立つと思いました。
業務で使うシーンを想定しながら、今回はそのコマンドと例文の一部をまとめようと思います。

代表的なテキストフィルタコマンド

コマンド	説明
grep	テキスト検索ツールで、指定したパターンに一致する行を抽出します。例: grep -i ’error’ application.log application.logファイル内で ‘error’ （大文字小文字区別なし）に一致する行を検索して表示します。
sed	ストリームエディタで、テキストの置換や削除、挿入を行います。例:sed ‘s/localhost/127.0.0.1/g’ /etc/hosts ホスト名をIPアドレスに置き換えます。設定ファイルを一括して修正する際に役立ちます。
awk	テキスト処理言語で、テキストのパターンマッチングと処理が可能です。例:awk ‘$3 == “root” {print $1}’ /etc/passwd /etc/passwdファイルからrootユーザーのユーザー名を抽出します。
sort	テキストデータをソート（並べ替え）します。例: sort -k3,3 -t, data.csv CSVファイルの3列目（例: 売上データ）を基準にしてソートします。
uniq	重複する行を削除します（通常はsortと組み合わせて使用されます）。例: sort access.log \| uniq -c アクセスログの重複するエントリを集計し、一意のリクエスト数を数えることができます。
cut	テキストの特定のフィールドを抽出します。例: cut -d ‘:’ -f 1 /etc/passwd /etc/passwdファイルからユーザー名のみを抽出します。
tr	文字の変換や削除を行います。例: echo ‘abc123’ \| tr ‘a-z’ ‘A-Z’ 出力結果の小文字を大文字に変換します。

これらのコマンドを使いこなすことで、テキストデータの効率的な処理と分析が可能になります。

おわりに

今回の記事では、LinuC101試験に向けての学習の一環として、GNU/Linuxの歴史やリチャード・ストールマンの貢献、そしてテキストフィルタコマンドについてまとめました。これらの知識を深めることで、Linuxシステムの理解がさらに深まったと感じています。特に、シェルスクリプトの作成や自動化されたデータ処理、システム管理業務において、これらのコマンドの組み合わせが強力なツールとなることを理解しました。また、実際の業務でのデータ処理や、エラーの迅速な検出・修正など、より効率的なシステム運用に役立つ点も大いに学ぶことができました。

今回はここまで
最後までご覧いただきありがとうございました！

ITパスポートの試験を受けました！紙屋04

お疲れ様です！
’23年度入社の紙屋です！
12月に入り本当に寒くなってきました。
こんな季節は温泉にゆっくりつかって、コタツで丸くなりたいですね！

さて、この業種について9か月が経とうとしています。
未経験で入社し、外部研修や日々の学習や課題をこなしてきました。今もOJTとして少しずつ実際の案件に携わらせてもらっています。
分からないことの方が多く、教えていただいてもなかなか理解ができないことの方が多い毎日です。
なので、基礎知識の学習という意味でもITパスポート試験を受けることにしました。

ITパスポート試験とは何か？

ITを利活用するすべての社会人・これから社会人となる学生が備えておくべき、ITに関する基礎的な知識が証明できる国家試験
https://www3.jitec.ipa.go.jp/JitesCbt/html/about/about.html

とのことです。
確かに、前職は全く違う分野でしたが、ITなくして業務は成り立ちませんでした。
基礎的知識を学ぶためにもちょうどよい機会かなと思い、チャレンジしました！

内容は、新しい技術(AI、IoT など)や手法に関する知識、経営全般の知識、IT(セキュリティ、ネットワークなど)の知識、プロジェクトマネジメントの知識など幅広い分野にわたります。

実際の試験は100問(/120分間)あり、ストラテジ系、マネジメント系、テクノロジ系と3分野に分かれ、合格基準点は3分野それぞれ300/1000点以上正答し、合計で600/1000点以上あれば良いとのこと。

勉強期間は約2か月間。
最初はテキストの内容をまとめ、各章末問題を解き、試験前は過去問をひたすら解きました。
広く知識を求められ、テキストを通るだけでもかなりのボリュームがありました。
適宜まとめた内容を上長へレビューいただきましたが、広い分野に対しても必ずコメントをいただき、アドバイスもいただいて、その知識量に逆に怖くなりました(笑)

どれも知らない知識ばかりで、特にストラテジ系とテクノロジ系が難しかったです。
3,4文字のアルファベットの略語は暗号にしか思えず、関数の条件式を問うような問題ではまず問題文の理解に苦しみました…
過去問で類似問題を数回解くことでなんとか少しずつ覚えていきました。

過去問を解き始めたころは5,6割の正答率でした。過去問を数回解くことで正答率は7,8割まで安定してきたので、「よし！いける！」と自信満々で試験を受けに行きました。
今までも国家試験を受けてきたので特に緊張はしませんでした。
受験者の中には管理職ぐらいの年代の方から小学生までいて驚きました！

試験の方は、苦手分野のストラテジ系でさらに新しい単語が出題され、とても焦りました…(汗)
利益やコストの計算や関数の条件式を問う問題など、計算問題が過去問より多く、それでも焦りました…(汗)
残り時間20分ぐらいでやっと一通り解答できましたが、見直ししたい問題が多すぎて「詰んだー」と焦りました…(汗)

試験後はすぐに解答され、ギリギリ基準点は満たすことができて一安心。
覚えも悪くなってきているなと痛感した1日でした。
今回の勉強の熱が冷めないうちに、勉強を続けてさらなる挑戦に挑みたいと思います。
また何か動きがあれば決意表明をしたいと思います！
では、また次回!!

LinuCの試験について

こんにちは。22年度入社の中島です。

この間、Linux資格のLinuCを受験しました。
今回私が受けたのは、LinuCレベル1（101試験）になります。
この試験は、101試験と102試験があり、認定されるためには2試験を（片方を合格していたら5年以内に）合格する必要があります。

今回は、LinucCレベル1 101試験を受けた感想や試験の内容を簡単に書いていこうと思います。

・Linux技術者認定「LinuC（リナック）」とは
クラウドやDX時代のITエンジニアに求められるシステム構築から運用管理に必要なスキルを証明できる技術者認定です。

・受験動機
この試験を受ける理由は、仕事に対する自信につなげられるようにするためと、これからの業務の役に立つと思い受験しました。

・予約と受験方法、前日までの準備について
今回はオンラインでの受験だったので、テストセンターでいかなくてよかったのですが、
試験を受けるにあたっての、本人確認書類の用意、受験スペース準備や規則などが大変でした。

・試験対策と試験概要
対策として、テキストでの学習や過去問を解くなどをしていました。一日に学習する範囲を決めてやったり、章まとめの問題集を何回も解きなおしていました。

LinuCレベル1（101試験）は試験時間は85分で出題数は60問でした。
以下は試験囲です。

第1章:　Linuxのインストールと仮想マシン・コンテナの利用
第2章:　ファイル・ディレクトリの操作と管理
第3章:　GNUとUnixのコマンド
第4章:　リポジトリとパッケージ管理
第5章:　ハードウェア、ディスク、パーティション、ファイルシステム

・勉強してみた感想
Linuxのことを何もわからない状態からのスタートだったので、なんとなく理解するのにも時間がかかりました。
特にコマンドとそのオプションを覚えきれず、とても苦労しました。

・結果と感想
結果は残念ながら不合格でした。
１～５章の全範囲まんべんなく出ていたので、全体的に復習が必要だと思いました。
受験した感想といたしましては、どのような形で問題が出されるのかわからず、緊張して問題とくペース配分がうまくいかず、時間が掛かりました。
それによって見直しを行う時間がありませんでした。
また、第3章、第4章のコマンドを忘れていたり、コマンドは合っているのにオプションを間違えてるなどのミスが目立ちました。

今回の試験で自分の努力不足をとても感じました。次回受験する際には過去問やりこみ、解くスピードを上げて見直しをする時間を作りたいと思います。模擬試験で正解8割を安定して出せるようになってから再度、受験したいと思います。

現在は、ping-tというサイトを使って過去問を解いています。
このサイトは、試験範囲・問題数・出題形式まで自由に決めることができて便利です。
間違ってもわかりやすい解説があるので、おすすめです。(アカウント登録が必要です。)

https://mondai.ping-t.com/users/sign_in

いかがでしたでしょうか。

久しぶりのブログでしたが、よいネタを見つけたら投稿していきたと思います。

最後までご覧いただきありがとうございました！

PHPUnit_その３(データプロバイダ)

福岡拠点の永嵜です。

前回に引き続きPHPUnitの機能を紹介します。

今回はデータプロバイダ機能を紹介します。
データプロバイダ機能とは、テストメソッドに任意の引数を渡せる機能です。
データプロバイダを使用すると同じテストメソッドで様々なテストができる利点があります。

データプロバイダ機能

例題を示しながら説明します。
前回使用したテストケースにデータプロバイダを追加します。

■テストケース

class AreaCalcTest extends TestCase
{

    /**
     * @dataProvider traiangleProvider
     */
    public function testGetTriangleArea($width,$height,$expected)
    {
        
        $actual = AreaCalc::getTriangleArea($width,$height);
        
        //$expected と　$actualが等しくない場合エラー
        $this->assertEquals($expected,$actual);
    }
    
    public function  traiangleProvider()
    {
        return [
            'ok pattern' => [4, 2, 4],
            'ng pattern' => [4, 2, 10],
        ];
        
    }

}

class AreaCalcTest extends TestCase

{

/**

* @dataProvider traiangleProvider

public function testGetTriangleArea($width,$height,$expected)

{

$actual = AreaCalc::getTriangleArea($width,$height);

//$expected と　$actualが等しくない場合エラー

$this->assertEquals($expected,$actual);

}

public function traiangleProvider()

{

return [

'ok pattern' => [4, 2, 4],

'ng pattern' => [4, 2, 10],

];

}

traiangleProviderメソッドがデータプロバイダになります。
[4, 2, 4]、 [4, 2, 10※1]がテストメソッドに渡す引数になります。
[横、縦、想定値]のデータをテストメソッドに渡します。
配列一つが1テスト用のデータになります。

※1 今回データプロバイダの説明のために想定値に誤った値を設定してテスト失敗を発生させています。

データプロバイダのデータにラベルを付けることができます。
(‘ok pattern’/’ng pattern’)
ラベルを付けることによってテスト失敗時にどのデータで失敗しているかを確認しやすくなります。
データプロバイダからデータを受け取るにはテストメソッドに@dataProviderアノテーションを付けます。

■実行

vendor\bin\phpunit test\
PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

.F                                                                  2 / 2 (100%)

Time: 853 ms, Memory: 14.00 MB

There was 1 failure:

1) Tests\Unit\Test\AreaCalcTest::testGetTriangleArea with data set "ng pattern" (4, 2, 10)
Failed asserting that 4 matches expected 10.

/var/www/everegi/tests/Unit/Test/AreaCalcTest.php:20

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.

vendor\bin\phpunit test\

PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

.F 2 / 2 (100%)

Time: 853 ms, Memory: 14.00 MB

There was 1 failure:

1) Tests\Unit\Test\AreaCalcTest::testGetTriangleArea with data set "ng pattern" (4, 2, 10)

Failed asserting that 4 matches expected 10.

/var/www/everegi/tests/Unit/Test/AreaCalcTest.php:20

FAILURES!

Tests: 2, Assertions: 2, Failures: 1.

‘ng pattern’のデータでテスト失敗となりました。

また、実行時にfilterオプションを使用すると実行したいテストデータだけテストすることができます。

■データ指定(ok pattern)で実行

vendor\bin\phpunit test\  --filter '@ok pattern'
PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 711 ms, Memory: 14.00 MB

OK (1 test, 1 assertion)

vendor\bin\phpunit test\ --filter '@ok pattern'

PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

. 1 / 1 (100%)

Time: 711 ms, Memory: 14.00 MB

OK (1 test, 1 assertion)

最後に

前回、今回、PHPUnitの概要を説明しましたが、PHPUnitには
コマンドオプション、アノテーション、アサーションなど他にも便利な機能があるので詳細を知りたい方は下記をチェックしてみてください。

PHPUnit マニュアル

https://phpunit.readthedocs.io/ja/latest/index.html

PHPUnit_その２(実行手順)

福岡拠点の永嵜です。

前回に引き続き、PHPUnitを紹介します。
今回はPHPUnitの実行手順を紹介します。実行環境は前回 Composer を使用してインストールした環境で行います。

PHPUnitの実行

PHPUnitでは理解するべき３つの要素があります。

①テスト対象クラス
ユニットテストを行うテスト対象のクラスです。

②テストケースクラス
テストケースは原則としてテスト対象クラスに対して1つ作成します。テストケースは、PHPUnit\Framework\TestCase※1 を継承して作成します。一般的にテストするクラス名の末尾に「Test」という文字列を付与したものをテストケース名とします（ファイル名はテストケースクラス名.php）。

- テストケースクラス名 ：「[テストするクラス名]Test」
- ファイル名 ：テストケースクラス名.php

※1:vendorフォルダー配下にあります。

③テストメソッド
テストケース内に記述するメソッドです。実際にテストをする単位となります。
テストメソッドの名称は「test」で始まる文字列にする必要があります。
※@testアノテーションを使用する場合は、「test」でなくてもよいです。

では実際にテストケースを作成し、実行してみましょう。

まず、開発用ディレクトリにテスト対象クラスを格納する src ディレクトリとテストケースクラスを格納する test ディレクトリを作成します。

■テスト対象作成

テスト対象となるクラスを用意します。

<?php

namespace Sample;

class AreaCalc
{
    /**
     * 三角形の面積を算出
     * @param int $width
     * @param int $height
     * @return double
     */
    public static function getTriangleArea($width,$height)
    {
        return $width*$height / 2;
    }
}

<?php

namespace Sample;

class AreaCalc

{

/**

* 三角形の面積を算出

* @param int $width

* @param int $height

* @return double

public static function getTriangleArea($width,$height)

{

return $width*$height / 2;

}

引き数で横、高さを受け取り三角形の面積を返すクラスです。

■テストケースとテストメソッド作成

テスト対象が完成したらテストケースとテストメソッドを作成します。
test ディレクトリに AreaCalcTest.php ファイルを作成し、次のように記入します。

<?php
require_once('vendor/autoload.php');

use PHPUnit\Framework\TestCase;
use Sample\AreaCalc;


class AreaCalcTest extends TestCase
{
    
    /**
     * @group getTriangleArea
     */
    public function testGetTriangleArea()
    {
        $width = 4;
        $height = 2;
        $expected= 4;  // 期待値 4×2 /2 = 4

        $actual = AreaCalc::getTriangleArea($width,$height);
        
        //$expected と　$actualが等しくない場合エラー
        $this->assertEquals($expected,$actual);
    }
    
}

<?php

require_once('vendor/autoload.php');

use PHPUnit\Framework\TestCase;

use Sample\AreaCalc;

class AreaCalcTest extends TestCase

{

/**

* @group getTriangleArea

public function testGetTriangleArea()

{

$width = 4;

$height = 2;

$expected= 4; // 期待値 4×2 /2 = 4

$actual = AreaCalc::getTriangleArea($width,$height);

//$expected と　$actualが等しくない場合エラー

$this->assertEquals($expected,$actual);

}

このテストケースでは、$width(横)と $height(高さ)で計算した面積が正しいかをテストしています。テストメソッドではアサーションと呼ばれる結果判定メソッドを使用します。今回の例ではassertEqualsがアサーションメソッドになります。
ちなみにassertEqualsは2 つの引数が等しくない場合エラーとするメソッドです。
$expectedに想定値、$actualに実測値を設定しassertEqualsで判定しています。

図1のように開発用ディレクトリ(Sample)内にテスト対象(AreaCalc)とテストケース(AreaCalcTest)を配置しています。

■実行

phpunit コマンドを実行してユニットテストを行います。
phpunitはPHPUnitをインストールしたディレクトリのvendor\binフォルダ配下にシンボリックリンクがあります。

全てのテストケースの実行、特定のテストケースだけ実行どちらもできます。
今回はテストケースが1つですが①の方法で実行します。

①テストケースを全て実行する場合
・vendor\bin\phpunit テストケース保存フォルダ
⇒例：vendor\bin\phpunit test\

②テストケースを指定して実行する場合
・vendor\bin\phpunit テストケース指定
⇒例：vendor\bin\phpunit test\AreaCalcTest

※上記方法以外にもコマンドオプションで制御する方法があります。詳しくは PHPUnitマニュアルをご確認ください。

コマンドプロンプトを開き次のように入力します。
test ディレクトリ内のファイルをテストケースとしてテストが実行されます。

vendor\bin\phpunit test\

1	vendor\bin\phpunit test\

■テスト結果

テストが実行されるとテスト結果ステータス(4行目)が表示されます。
AreaCalcは正しい結果を返す状態なので( $width = 4、 $height = 2を引数で与えると4が返ってくる)テスト成功.（ドット）となっています。

PS C:\xampp\htdocs\Sample> vendor\bin\phpunit test\
PHPUnit 8.0.4 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 3.24 seconds, Memory: 4.00 MB

OK (1 test, 1 assertion)

PS C:\xampp\htdocs\Sample> vendor\bin\phpunit test\

PHPUnit 8.0.4 by Sebastian Bergmann and contributors.

. 1 / 1 (100%)

Time: 3.24 seconds, Memory: 4.00 MB

OK (1 test, 1 assertion)

他のステータス表示は以下のようになります。

ステータス	意味
.（ドット）	テスト成功
F	テスト失敗
E	テストが危険としてマーク
S	テストをスキップした
I	テストが未実装

以上がPHPUnitによる一連のテスト手順となります。

次回は今回実行したサンプルプログラムに手を加え、
データプロバイダ機能について説明したいと思います。

PHPUnit_その１(インストール)

福岡拠点の永嵜です。

PHPUnitを使用する機会があったのでPHPUnitの使い方を紹介します。

本ブログでは下記の流れで説明していきます。
・PHPUnitの概要
・PHPUnit のインストール
・PHPUnitの実行

PHPUnitの概要

■PHPUnit
PHPで実装されたプログラムのユニットテスト(単体テスト)※1を自動化するためのテスティングフレームワークです。

※1:ユニットテスト
ユニットテストとはクラスや関数などプログラムを構成する小さな単位(ユニット)で個々の動作を確認するためのテストです。

PHPUnit のインストール

■PHPUnit のインストール
PHPUnitを使用するためにPHPUnitのインストールを行います。
インストールは下記方法があります。
・公式サイトから直接ダウンロードする。
・Composer を利用する

今回はComposerを利用した手順でインストールを行います。

①開発用ディレクトリに composer.json を設置し、次のように記入します。

{
    "require-dev": {
        "phpunit/phpunit": "*"
    }
}

{

"require-dev": {

"phpunit/phpunit": "*"

}

②コマンドプロンプトで下記コマンドを実施します。

composer update

1	composer update

③インストール結果を確認します。
・開発用ディレクトリにcomposer.lock ファイルと vendor ディレクトリが生成されます。
・下記コマンドを開発用ディレクトリにで実行しPHPUnitが実行できることを確認します。
実行ができたらインストールしたPHPUnitのバージョンが表示されます。

vendor\bin\phpunit --version

1	vendor\bin\phpunit --version

以上がPHPUnitのインストール手順となります。

次回はPHPUnitを実行する手順について説明したいと思います。

2025年12月
月	火	水	木	金	土	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31