はじめに Alexaのスキル開発をしていると、実機やテストシミュレータを使ったユーザーテストだけではだんだんと辛くなってくるケースがあります。 できれば、スキルで行われる会話についてもローカルで自動テストをしたいところです。 今回は、Virtual Alexaというツールを使ってAlexaスキルの会話テストをローカルで行う方法をご紹介します。 Virtual Alexaとは Bespoken Toolsなどを提供するBespoken社による、Alexaスキルのテストやデバッグを行えるライブラリです。 NPM - virtual-alexa Virtual Alexaを使うことで、バックエンドLambdaのハンドラについてのテストやダイアログモデルのテストを簡単に書くことできます。 検証環境 Node.js 8.10 ASK-SDK 2.5.0 Yarn 1.13.0 Virtual Ale
![[Alexa] Virtual Alexa + Mocha を使ってスキルの会話を自動テストする | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1bfa19e4d1bf81d5518adb87988b0d115ab86ff2/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F12%2Falexa-eyecatch.jpg)
/// <summary> /// 在庫データ /// </summary> public class ProductStock { public long Id { get; set; } /// <summary> /// 仕入れ数 /// </summary> [ConcurrencyCheck] public int PurchaseQuantity { get; set; } /// <summary> /// 販売済み数 /// </summary> [ConcurrencyCheck] public int SoldQuantity { get; set; } /// <summary> /// 残販売可能数 /// </summary> [ConcurrencyCheck] public int RemainingQuantity { get; set; } } publi
JavaでDBのテスト 実際のテストでめんどいDBのテストデータの準備とDBの状態のテスト。これまではDBUnitしか使ったことなかったけど、Dbsetupでテストデータを準備し、AssertJ,AssertJ-DBでDBのテストをやってみた。 DBUnit http://dbunit.sourceforge.net/intro.html データを外部ファイルで管理して、Assertionも期待値を格納したファイルと比較して書ける。 // Fetch database data after executing your code IDataSet databaseDataSet = getConnection().createDataSet(); ITable actualTable = databaseDataSet.getTable("TABLE_NAME"); // Load exp
はじめに 今回は、プログラム開発では大活躍！単体テストで使用できるフレームワーク、「DBUnit」の使い方を紹介します。 DBUnitとは、Javaで使用するテスティングフレームワークの一つなのですが、筆者が勉強した感じでは、記事が古かったり、それだけで完全に事足りるwebが少ないように見受けられたので、筆者の備忘と、この記事をご覧いただいた方への共有も兼ねて、こちらにまとめておきます。 参考としてwebに資料を記載いただいている優しい方も、たくさんいらっしゃるんですけどねorz 1. DBUnitとは 先にも記載しましたが、DBUnitとは、Javaプログラムのテスティングフレームワークの一つです。 テスティングフレームワークと聞くと、XUnitを想像されるかと思います。 今回の対象はJavaで実装したプログラムですから、よく使用するのはJUnitですが、DBUnitもJUnitと一緒に
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするかという記事がバズりました。みんなテストについて思うところがあるようだ。テストを書くべきか否かは机上の空論になりがちで不毛なので、どうやってテストを書くか、テストの書き方、について、種を巻いた私が書いておく。 もっと詳しい方からのお話お待ちしています。 書くこと テストの書きやすくするためのいろいろ（箇条書き） 書かないこと テストの基本 テストファースト 実装ありきでテストを書くのではなく、テストありきで実装を変える。 はっきり言って、テストを考慮せずに実装されたコードは、書き直さずにはテストできない。 そういう点で、テストなしで実装する選択肢は不可逆なので、初期実装では特に注意が必要。 クリーンアーキテクチャ(DDD) クリーンアーキテクチャの考え方はテストファーストを語る上で重要。私個人としてはまだクリーンアーキテクチャ
はじめに Alexaスキルを実装するときにもテストしながら開発したい。 でも、実機で声を出しながら実装するのは流石に効率が悪い。 Alexaシミュレータを使うのも繰り返していると辛くなってくる。 コードを変更するたびに Lambda関数をデプロイするのも辛いし、Alexaシミュレータに発話を入力するのも面倒。 なにより、エラーになったときに発生箇所がわかりにくく、デバッグログを仕込んではCloudWatchLogsで確認するのが辛い。 ローカルでテストしながら開発できないものか。。。 ということで Jest + virtual-alexa でAlexaスキルをテストする方法を紹介する。 開発環境 最初に私の開発環境について、記述する。 AlexaスキルのバックエンドはLambdaを利用している。ランタイムはNode8.10。ローカルのテストにおいてもNode8.10を利用している。 Typ
.NET Core + SQL Server のユニットテストを Bitbucket Pipelines で動かしてカバレッジレポートを作成する Java から .NET Core に入門した身としては CI をどうするかはよくわからない問題です。 VSTS や Visual Studio にべったり依存すれば方法はあるのかもしれませんが、 なるべく GUI ツールではなく、テキストベースのスクリプトでビルドやテストができるような方針でありたいものです。 そこで最初に考えたのは、 Jenkins 2 系の Jenkinsfile のビルドスクリプトを使ったものでした。 当時は .NET Core Linux 向けのカバレッジ計測が出させるライブラリがなく、Windows サーバーで動かし OpenCover を使っていました。 Ver.UP で動かくなったり、ライブラリの導入自体が面倒だっ
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
サーバーレス開発部では、AWS Lambda の Lambda Function をひんぱんに開発します。Lambda Function はその特性上、アプリケーションサーバーを持たず、Function として登録すればすぐに動かせます。また、接続するAWSサービスは多岐に渡り、プログラムから接続するためのSDKも用意されています。 Lambda Function の開発で感じる課題 開発を続ける中でいくつか課題を感じました。最初に思ったのは どこで開発すればいいんだ ということです。AWSのコンソールにいくと、 Lambda Function のためのエディタが埋め込まれており、そこで直接開発することもできます。便利！と思ったのですが、オンラインエディタはショートカットキーの制限などもあり、性に合いませんでした。また、複数の関数を作る場合の共通化や、複数メンバーで開発する場合のバージョン
前回、思いついた方法でやったけど、詰んだという話を書いた。 TDD を実施するために Moq を試してみた その２実践してみた 前回は師匠の言う通りと思って、お題の KeyVaultHelper の Mock はあきらめるという方針をとって、それはとても正解と思うが、プログラミングテクニック的に他のやり方で出来ないかを考えて実践したらうまくいったのでブログに書き留めておきたい。金で解決する方法と、シンプルな方法の二つをご紹介します。 師匠の一言 私の尊敬するプログラミング師匠があの後コメントをくれた。そういえば以前師匠はこういっていた。 C# での Mock は、Moq で。お金でぶん殴るなら、Fakesで 「お金でぶん殴る」というのはどういう意味かというと、Fakes という Mockツールは、Visual Studio Enterprise でしか使えない機能らしいのだ。マイクロソフ
Javaでのデータベースのテストデータ作成にはDBUnitがよく使われますが、自分はDbSetupをオススメします。 DbSetup なぜDBUnitがイマイチなのか 自分も最初はDBUnitを使ってたのですが、以下の理由からしっくり来ませんでした。 DBを使ったテストでは少量のデータを使うことが多い ホワイトボックステストで大量のデータを使うことはほとんどなく、単一または複数のテーブルに対して、少量のデータを用意するケースがほとんどです。なので、テストごとにファイル(XML or Excel)を用意するのは面倒です。 テストコードとデータが分離している テストデータを外部ファイルに保存するため、テストコードとテストデータが分離してしまっています。そのため、何をテストしているのかが分かり辛いです。 そこでDbSetup そこで見つけたのがDbSetupです。DbSetupはテストデータをJ
はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma
Get an email when there's a new version of TSQLUnit unit testing framework The project moved to GitHub, https://github.com/aevdokimenko/tsqlunit TSQLUnit is a framework to write tests for applications written in Transact-SQL. It follows the tradition of the "xUnit" framework that is available for almost all programming languages. Features Simple, lightweight and straightforward.Can be used in comp
データベース単体テストを使用すると、データベースのベースラインとなる状態を設定した後、データベース オブジェクトに対してそれ以降行う変更を検証できます。 ベースライン状態を確立する前に、まずデータベース プロジェクトを作成する必要があります。 テスト プロジェクトを作成し、データベース オブジェクトを実行する一連の Transact-SQL テストを記述します。 これらのテストを使用して、バージョン管理にオブジェクトをチェックインする前に、動作が正しいかどうかを分離開発環境で検証できます。 データベース オブジェクトに対する変更を検証するテストを作成できます。 さらに、データベースの関数、トリガー、およびストアド プロシージャをテストする Transact-SQL コードのスタブを自動的に生成できます。
Unit testing has been a common and accepted practice in application development for a long time. By testing certain functions and areas – or units – of code, it verifies those functions work as expected, and improves the quality of code. tSQLt brings the same advantages to SQL Server database development, and is compatible with all editions of SQL Server from the 2005 Service Pack 2 edition onward
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
