Javascriptの単体テストを書く(power-assert)

はじめに

単体テストについてはE2Eを組む前段で用意してたことはあるのだけれど、真面目に書くことがなかったのでpower-assertを使ってテストコードを書くことに挑戦してみる。

参考

みんなのPowerAssert github.com

インストール

$ npm install mocha espower-loader intelli-espower-loader power-assert --save-dev

ディレクトリ構成

.
├── node_modules
├── package.json
├── src
│   └── Calculator.js
└── test
    └── test.js

対象&テストコード

Calculator.js

module.exports = class Calculator {
  constructor(name){
    this.name = name;
  }
  plus(x, y){
    return x + y;
  }

  minus(x, y){
    return x - y;
  }

  divide(x, y){
    return x / y;
  }
};

test.js

const Calculator = require('../src/Calculator');
const calculator = new Calculator('riririusei99');
const assert = require('power-assert');


describe('Test plus', function(){
  it('shoud return 3 when value is number', function(){
    assert(calculator.plus(1,2) === 3);
  });
  it('【ERROR SAMPLE】shoud return "12"', function(){
    assert(calculator.plus("1","2") === 12);
  });
});

describe('Test minus', function(){
  it('shoud return 3 when value is number', function(){
    assert(calculator.minus(5,2) === 3);
  });
  it('shoud return -2 when value is number', function(){
    assert(calculator.minus(3,5) === -2);
  });

});

describe('Test devide', function(){
  it('shuoud return 1 when value is number', function(){
    assert(calculator.divide(5,5) === 1);
  });
  it('shuoud return error when 0 divide', function(){
    assert(calculator.divide(5,0) === Infinity);
  });
});

テスト実行

power-assertのREADMEを参考に実行する

$ node_modules/mocha/bin/mocha --require intelli-espower-loader test/test.js

こんな感じで出力される f:id:riririusei99:20180608202737p:plain

おわりに

環境の準備は割とさっくりできた。
テストの書き方とかが大事なんだろうなぁというかんじなので、次回はもう少し複雑なコードに対してテストを書いてみるみたいなのをやってみたい。
CTFで作ったお遊びスクリプトとかがちょうど良さそう。

今回できたもの

github.com

Jenkins pipelineを触ってみた

はじめに

最近の仕事でJenkinsのデプロイジョブとE2Eのジョブの2つを作ったので、ここらへんでpipelineを使って2つのジョブをつなげて一目で確認できるようにとpipelineについていろいろ調査して挑戦しました。

ざっくりと書いたもの

実際はブランチの他にも組織名とかいろいろパラメータがあるのだけれど簡素に書くとこんな感じ。
ここまで実装するためにいろいろ調べて時間がかかった…もう見つけられないかもしれないと思うと怖くなったので、自分のブログに残しておく。

PipelineScrip

node {
     //  ステージを設定する
    stage ('build') {
        build job: 'build',  parameters: [
            //  ジョブに渡すパラメータを設定する
            [$class: 'StringParameterValue', name: 'BRANCH', value: 'ブランチ名']
        ]
    }
        
    stage ('test-setting') {
        build job: 'E2E-A'
    }
}

おわりに

Jenkins側のジョブを分けつつ、自動テストの粒度も小さくすることで「前のバージョンでデータを作って、最新バージョンにデプロイし直してテストする」みたいなこともできると思うといろいろ便利だと思いました。
バージョンアップテストとかってどうするのかって思っていたけれども自動化のアプローチとしてpipelineを活用するってのもありかもしれないと思いました。

参考

下記参考にしたもの

jenkinsのpipeline入門(jenkinsfile) - SIerだけど技術やりたいブログ

Jenkins2のPipline参考リンク集

【Jenkins】パイプラインからジョブを呼び出す際、パラメータを指定する - 自分の速さで

ParameterValue (Jenkins core 2.125 API)

readコマンドを使ってスクリプトを書いてみる

はじめに

普段使ってるシェルスクリプトはユーザー&パスワードはほぼほぼ固定なんだけど、たまに任意の入力を受け付けて実行したい時がある時の話。
調べたところreadコマンドを使うのがよさそうというのと…

shellを書く時にはたいてい記憶が空になっているので、自分のための備忘録。

read コマンドを使ってスクリプトを書いてみる

readInput.sh

#!/bin/sh

echo "ユーザー名を入力してね"
read inputUser
echo "PASSWORDを入力してね"
# -sでpass入力
read -s  inputPass

echo "$inputUser にデプロイするよ? y/n"
read input

if [ $input == "yes" ] ||[ $input == "y" ]
then
    echo "$inputUser で処理するよ"
    # 処理を書く
else
    echo "終了するよ"
    exit
fi

おわりに

作り終わったタイミングで、実務ではJenkinsのパラメータ付きビルドで同じ事を出来ることに気づいてしまった…。
何事も経験ですよね!ということでお茶を濁すことにします。。。。

おわり

最近見た映画

1ヶ月ぶりに記事を書くのですが…ネタが思いつかず…。

趣味の話をします😋

 

週末にレイトショーを見るのが最近のマイブームで、色々考えたり、テンション上げたりしてます。

 

ということで最近見た映画の紹介(3月、4月)

 

グレイテストショーマン

ヒュー・ジャックマン演じるジャン・バル…じゃなくてP.T.バーナムの半生を描いた映画。

ミュージカル映画なので音楽が良い、すごく良い。

見た翌週はSpotifyでサントラ聞いて仕事してました。

本当に大切なものはなんだっけと問いかけてくれる楽しめる映画です。

 

レッドスパロー

ロシアの才能あるバレリーナだったドミニカは怪我をきっかけに怪しい叔父さんの仕事をきっかけにスパイになる映画。

スパイとして望まないながらも成長していく姿はなんだか、考えさせられるよね。

騙し合いの騙し合いで、最後までどうなるか分からない映画でした。

 

ヴァレリアン

気分が凹んでいたので観たらスッキリするだろうとポスターで選んだSF映画

思った通り、シンプルなストーリーで楽しく見れました。構成がぶつ切り感があったのでいくらでも続編作れそう。

 

パシフィック・リム アップライジング

前作をみてテンション上がったので観た。ロボットアクション、燃えるよねみたいな方は是非。吹き替えがオススメです。

 

…という感じで月2本位のペースで映画館に通うのも結構面白かったので、オススメの映画あったら教えて欲しいなぁ。

 

おわり

 

 

 

転職を決意した話

はじめに

2017年の9月に転職して半年が経ち、そろそろ振り返っておく意味でブログを書こうと思います。今回の話は転職を決意するまでの2016年の夏から2017年の冬の半年くらいの内容になります。

自分の話(当時)

  • パートナーのQA(Quality Assurance)として1年半くらいスクラムチームに在籍
  • 自社では初めてのQAなのでキャリアパスとかフォロー体制とかはない
  • スクラムチームを横断したQAチームのリーダー
  • 業務内容は自動テストのメンテやテストプロセスの改善
  • 手動テストは作り直しによる速度改善とかパフォーマンスアップのテストがメイン(軽めの案件は別のQAが担当で、計画会でやばい案件は自分みたいな感じ)

ちなみに、前回ブログで書いたチームを離れる時の話が今回のスタート地点です。
riririusei99.hatenadiary.jp

当時のスクラムチームの話

(自分から見れば)チームは成熟していて、離れる人は新しいチームを作る時のコアメンバーとしてチームを離れ、入る人は経験を積ませるために参画する…みたいな結構影響がありそうな体制変更もなんだかんだ受け入れられるチームでした。 メンバー変更のインパクトを残ったメンバーが覚醒することでチーム力を維持する…みたいなチームになっていました。(当時のスクラムマスターの心境をお察しします…。)
自動テストの師匠が抜ける時は本当に大変でしたが、裏側まで見られるようになったので結果的に自分の成長になったのでいい経験でした。

前職(SIer)のアジャイルQA事情

運用をメインでやっていたSEがQAとして開発チームに参画するといった展開は上層部に偉く魅力的に映ったらしく、「QAを増やすにはどうすればいいのか」みたいなことを毎週毎週、根掘り葉掘り聞かれ、新しい案件の引き合いがあれば候補の中には大抵自分の名前が上がっているような状態でした。
なのでJSTQBの資格取得を目指すとか、オススメ書籍の購入をお願いしたりとか、自動テストのリポジトリ・開発規約を作って業務を受けられるようにするとかQAをキャリアパスに乗せる環境づくりについていろいろ提案・実施しました。
QAメンバー自体は引き合いがあるので多い時は5人まで増えましたが、どれも中途半端な状態で止まってしまっていた印象です。

白羽の矢が立ったその裏で…

そんなこんなで、同じ現場で肝入りのプロジェクトがテストフェーズに入る前にQAとしてテスト全般の舵取りをお願いしたいということで最初のスクラムチームを離れることになります。リリース後には保守案件のスクラムチームが発足するのでそこのQAプロセスもお願いするかもみたいなオプション付きでした。
ここでは結合テストから受け入れテストを一手に引き受けるテストマネージャみたいな仕事をしつつテストを実施したり、強化テスト用のスポットで発足したテストチームのマネジメントしたり、品質評価のインシデント分析したり貴重な経験ができました。なんだかんだお客さんに気に入られ、大変そうなリーダーのサポートもお願いされるなどそれなりには貢献できたのかなと思います。

…その裏で、「QAを増やすにはどうすればいいのか」といったアプローチを着々と決めている様子で、どうも今のプロジェクトが終わった際にはスクラムチームには合流しないで別の現場でQAとして働きQAチームを作るみたいな流れになっていました。

転職を決意する

育ててくれたチームに恩を返したい。

慣れない新しい仕事ができるようになるのは、自身の頑張りももちろんですがその時一緒に働いた人のフォローがあってやり遂げられたと思っていて、できるようになった領域の仕事はその場所に還元したいと思っていました。
還元できると思う頃には次の現場が決まってしまうので、今の働き方では大切にしたかったことは実践できないなと思いました。
新しいスクラムチームのテストプロセスを考えながらも、未来のチームに自分はいないのが分かっていうのも思い返してもつらい仕事だなと思いました。

現場の人間を大切にして欲しい。

もう一点はネガティブな話になるのですが、改善してほしいと意味を込めてきちんと書いておこうと思います。 これまで「QAを増やすにはどうすればいいのか」と言われ続けていましたが、本当に言いたかったことはきっとこんな感じだったのかなと思います。
「(お金をかけず、余った人材で、かつ短い期間で)QA(の契約)を増やすにはどうすればいいのか」だったのかなと。 そこにいる人にはあまり関心がなかったのかなと思っています。 自分自身も同じ環境で育っているのであまり強くは言えないですが、契約を優先して交代だったり増員のメンバーがQAの仕事に対して興味や関心がない人、極端にスキルが劣る人を補充するのは本当にやめてほしいと思っています。 育ててくれたチームに対して後任のメンバーがトラブルを起こし、リーダーとして以前所属したチームにトラブルを解決しに行く時は恩を仇で返しているような気持ちになりました。

…と言う状況で、別の現場に移動して同じことを繰り返すというのは個人的にも耐えられないなと思い転職を決意するのでした…。

まとめ

つらつらと書いてみたものの転職を決意しただけでこんなに長くなるとは思わなかったですが、こんな感じで転職を決意しました。
ここら辺の考えがベースになっているので転職エントリーでは活動の内容にクローズアップしてかければと思います。

QAエンジニアとしてのスタート地点を振り返ってみる

はじめに

なんだかんだスクラムチームでのQAエンジニアとしてのキャリアが4年目になったので今回のエントリーを書きました。
そういえばブログを書いているけど、自己紹介すらままならないのでこの辺で自分語りの記事も入れておくって側面もありつつ、 これからQAになる人に向けて、話すことを今のうちから貯めておこうっていう企画です。

QAエンジニアになったきっかけ

2014年の末、それ以前は常駐してBPOサービスを提供するSEとして運用業務・受け入れテストなどを2年半ほど業務に従事していました。
そんなところにスクラム開発でQAを探しているというお誘いがありました。
プロダクトオーナーがテスト&受け入れを行って、多忙ゆえに十分なテストが行うことができないことに課題感を持っていたっていうのが始まりです。

・・・

若くて勢いがあったのと、テスト&運用業務を通してドメイン知識のあるということで自分に白羽の矢が立ちQAとしてのキャリアが始まりました。
今思うとマネジメントな人が多い会社だったのもあり、運用プロジェクトのリーダーになるかなぁとか漠然と思っていたけど、テストで生きていくようになるなんて思ってもいなかったなぁという感じです。

最初のミッション

当時の自分に課せられたミッションをまとめると下記だったような気がします(チャレンジも含む)

  • 受け入れテストの実施
  • テストプロセスの改善
  • 品質の向上
  • テスト自動化

一番最初のMTGで「アジャイルテストの4象限」と「テスト自動化のピラミッド」の図を見せてもらったことについては今でも覚えています。
これから先、アジャイルQAを育成する機会があれば、まずこれを見せてあげようかなぁとか思います。

役割分担

f:id:riririusei99:20180221020826p:plain

これは実践アジャイルテストの図に方針を書き足したもの。
まずは最初に「受け入れテストの実施」など手動の領域を担当するのが最初のミッション。
将来は手動と自動の左上の領域もQAに任せていきたいという内容だった(と思う)。

それぞれの4象限について誰がメインで担当していくかを明示してくれたのでわかりやすかったと思う。
改めて思い返すと成長した時に期待する姿もしっかり言及しているし、心の中にこの図はいつもあります。

自動化戦略

f:id:riririusei99:20180221015949p:plain

こちらは自動化戦略の説明のために。 チームの自動化戦略として山の登り方はこうやって進めるという内容でした。
最小構成で作ったピラミッドを順々に大きくしていく…という文脈でGUIテストの自動化から最初に着手する必要があり、自動テストのシナリオを作ってくれってのもQAになりたての頃にやりました。
…そして当時作ったケースがその時入ってきた新人君にボロクソに言われるのだった。

当時のチーム構成

  • プロダクトオーナー
  • スクラムマスター
  • エンジニア(7人)
  • QA(1人)

当時のチーム構成はこんな感じ。
チームの方針は「分からないからこそ、型を意識する」みたいなチームでした。
まずは型を守って、少しずつ破っていき、ある程度したら型から離れていくみたいな進め方だったので初めてのスクラム開発としては馴染みやすいチームでした。

あとはスクラム開発自体を導入する最初のチームだったので各社が肝入りのメンバーをそれぞれぶつけてきた感じのチームだったのですごい人が多かったなぁ。。。 開発チームの一員で役割が違うだけという括りだったのですべてのセレモニーや会議に参加していたので本当によかった。

はじめに頑張ったこと

社内で初めてのQAだったのでモデルとなるキャリアパスがなかったので、当時が頑張ったことは下記です。

JSTQBの資格取得

テストの専任・プロなのでいろいろ調べて真っ先に取ろうと思った資格。
勉強してみると日頃の開発で使えそうな知識がたくさんあったのでオススメしたい。

界隈の勉強会の参加

テストの自動化やアジャイルテストに関わりそうなものは足を使って情報収集した。
いろいろ勉強会で分からないことを質問したら、同じような境遇の人と連絡先を交換したりしてこれはこれでよかったかも。

おわりに

当時のことを思い出していろいろ書いたので、また思いついたらここを直していきます。
そう考えるとまるまる3年はやってるのでそこらへんの整理は定期的にやるべきだと改めて思いました。
教えるのが下手くそな自覚はあるので次教える機会が来る近い未来までにはある程度形にしたいと思います。

オチ、書いた人の現在の雑な自己紹介(読み飛ばしてOKです)

私、riririusei99!QAエンジニアだよ! 最近転職してきたけど、憧れて入った先輩エンジニアがどんどん偉くなっちゃって、さぁ大変! ひょんなことからスクラムマスターも兼任することになって…どうすればいいの?? 次回、「ドキドキ☆スプリントプランニング」 お楽しみにー!

終わり

【まとめ】JavaScriptのE2Eフレームワークを触ってみる

はじめに

これまで5回に渡り書いたE2Eフレームワークを使ってみる系の記事は、We Are JavaScripters! @15th【初心者歓迎LT大会】 - connpassに登壇するにあたり書きました。
今回はLTに組み込めなかった補足とかを書ければ良いかなと思います。
事前に盛大にネタバレしていた訳ですが、LTは総集編だから良いだろうという目論見です wajs.connpass.com

発表資料

speakerdeck.com

E2Eフレームワークを使ってみる系の記事

Cypressを使ってみる - riririusei99’s blog
TestCafeを使ってみる - riririusei99’s blog
cinnamonjsを使ってみる - riririusei99’s blog
nightmare.jsを使ってみる - riririusei99’s blog
protractorを使ってみる - riririusei99’s blog

紹介したツールの選び方

LTの中で5つのツールを紹介したのですが、検討条件・紹介した理由みたいなのを書きます。

検討条件

  • テーマであるJavaScriptを使っているもの
  • 自分の勉強のため、これまで使ったことないもの
  • LTで紹介することを意識してテストコードの書き方に違いが出そうなもの

そこからぼんやりと紹介するテーマを選んでから紹介するツールを当てはめてみました。

紹介するラインナップ案(結果)

  • 拡張性が高い、いろいろカスタマイズできるもの(Protractor)
  • 導入が簡単で、単品で色々できるもの(Cypress)
  • Seleniumを使わないもの(Nightmare)
  • モダンな書き方ができる新しいもの(TestCafe)
  • テストケースの書き方に特徴があるもの(cinnamonjs)

※今回WebdriverIOやNightWatch.jsなどを紹介しなかったのは実は触ったことがあったのと、WebdriverIOはProtractor、NightWatchはCypressと方向性が近いかなということで紹介から外れています。
ちなみにpuppetterを使ったHeadlessChromeを使ったE2Eを紹介できなかったのは単純に触る時間がなかったためです…スミマセン。
触っていたら名前がカッコイイNightmareと入れ替えるか考えるので悩ましいですね。

LTの中でCypressを選んだ理由

現在の開発チームに導入することを考えた場合、我々の特徴として下記がありました。

特徴

  • 既に稼働している自動テストがある
  • 開発エンジニアに好まれるツールが良さそう

拡張性があるツールより、簡単に導入ができてレポーティングが便利なツールが望まれ、既存のテスト領域を補えるツールを考えた結果、Cypressが良いとしています。

f:id:riririusei99:20180110233044p:plain
Cypressの実施&レポート画面

やってみての感想

社内イベント以外で登壇したのは初めてだったので非常に緊張しました。

緊張しすぎて2番手だったのに頂いたお酒を1本飲みきった状態でLTに挑みました。
終わった直後は緊張か酔ってるの分からないくらい頭が真っ白になりました。
普段から登壇されている人は改めてすごいですね。

改めて、場を提供していただいたWeJSの皆様、ありがとうございます。

また発表するので精一杯で、質疑に対して正しい返答ができず本当に申し訳ないです。
次回頑張る&自分なりの回答をブログのネタにしますので大目に見て下さい。

最後に、資料をあげた後にたくさんの人に閲覧してもらう形になりいい経験になりました。

当初は簡単な暗号文を解析をしてくれるツールを作って、オリジナルコンテンツとしてFF10で使っていたアルベド語翻訳ツール(最近実況動画を見た)みたいなネタツールを作る話をしようと思っていました。

作った時のテンションで発表は到底できなかったので結果的に自分の仕事に関係するようなテーマを選んでよかったと思っています。
要所要所に笑いどころを入れようと考えて作ったのですが、同僚に指摘された通りポケモンの下りはやめておけばよかった。かなり恥ずかしい

本当にありがとうございます。過去は取り戻せないのでこれからを頑張ります。

といったところで勉強会の初登壇の話はこの辺で終わりです。
ここまで読んでいただきありがとうございました。

追記

発表資料がはてブでホットエントリーに取り上げられてちょっとバズりました。 b.hatena.ne.jp ありがたいです。

riririusei99