JUnit5 使い方メモ - Qiita
package sample.junit5; import org.junit.jupiter.api.Assertions; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.DisplayName; class JUnit5Test { @Test void fail() { Assertions.assertEquals(10, 8); } static class StaticClass { @Test void fail() { Assertions.assertEquals(10, 8); } } static class StaticTest { @Test void fail() { Assertions.assertEquals(10, 8); } } class InnerTest { @Te
春からBtoB Javaエンジニアとして働く君たちへ - jildin workers
どうも。ハゲタカです。 最近まじでハゲてきたんじゃないかと不安になっています。 先日、トラさんが良い感じの記事を書いてくれました。 jildin.hatenablog.com ちなみにトラさんは「Java」か「ruby」と言ってましたが、僕は「Java」か「C」だと思っています。 さて、今日はそんなトラさんの記事に便乗して、僕は「新卒で初めて開発者として仕事をする人に意識してほしいこと」を書きたいなと思います。ちなみに今回はBtoB Javaエンジニア編です。 コードに触る時間のうち９割は・・・ 前職の時、新人研修担当として３０人近い人数を見ていました。 そのときに「先輩相談させてください。」と僕のもとに駆け込んできた新人と話しているとある勘違いに気づいたのです。 彼らはみんな「コードを書くフェーズで悩んでいた」のです。 実装方針が思いつきません こうやって書いて見たんですけどOutOfM
Androidのテスティングフレームワークを選定してみる - Qiita
Androidで良い感じにテストするために、たくさんあるテスティングフレームワークを試して選定してみる。 環境 OS X Android Studio 1.0.2 テスト用サンプルアプリ 入力された値を足して表示するだけのサンプルアプリ（アクティビティを跨いだテストもしたいので2画面構成）。 リポジトリ https://github.com/shikato/AndroidTestSample 今回はこのアプリに対してテストする。 ロジックのテスト Android Testing Framework 標準でJUnitベースのAndroid Testing Frameworkが使える。 これまではJUnit3ベースだったけど、最近JUnit4がAndroid support libraryに含まれるようになり、JUnit4な記述でも簡単に書けるようになった。 JUnit4の導入 Android
JMeterとJUnitとMavenで独自プロトコルサーバーの負荷テストを自動化するぞ | GREE Engineering
こんにちは、インフラストラクチャ本部の@nagaseyasuhitoです。このエントリは GREE Advent Calendar 2014 10日目の記事です。昨日はイケメンmoritaさんによる男性エンジニアリングマネージャが長期育休を取った話でした。 エンジニアブログのアカウントは2年くらい前からあるのですが、これが初エントリになります。グリーでは比較的珍しいJavaEEを始めとしたサーバーサイドJavaアプリケーションの開発、SolrやHadoopといったミドルウェアの周辺機能開発や運用などを行っています。どうぞよろしくお願いします。 最近はPvE/PvP/GvGなどユーザー同士がリアルタイムに協調プレイする際、クライアント-サーバー間を常時接続通信で行うゲームが増加しています。このような場合はHTTPのREST APIなど慣れ親しんだプロトコルでは要件を満たしきれないため、Web
DBUnitを使って、ユニットテストのテストデータを作成する
弊社ではテストのエビデンスとして、JUnitの結果とコードのカバレッジを提出するルールにしておりますが、開発者それぞれの環境でallTestをするようなこともあります。その時に環境によっては、マシンのスペックが悪くallTestにけっこう時間が掛かってしまうこと、またその影響でマシンの負荷が高くなり、他の作業を並行してやれず仕事にならないようなことがありました（注1）。その対応としてJenkinsにブランチのallTestが流せるジョブを作って対応しました。 あと、Jenkinsのバージョンはこまめに更新した方が良いなと実感しました。バージョンアップする前はビルド、AllTest、ページビューなどが結構遅くて、周りの人からも遅いという声があがっていました。改善として、サーバのスペックをすぐに上げることは無理そうだったので、jvmのチューニングをしたりしましたがさほど効果はなく、Jenkin
Android のテストで設計をイイカンジにしよう - Qiita
Android フレームワークは、あまり強力とはいえないものの、ある程度のテストフレームワークを内包しています。 ベースが JUnit3 なので、記法が古かったりすることもありますが、とりあえず JUnit3 の作法を身に付ければある程度のテストは書くことが出来ます。 Android のテストケースフレームワーク Android がもつ各種のコンポーネントをテストするためのフレームワークが有ります。 いろいろな種類がありますが、おそらく最も頻繁に使うのはAndroidTestCaseでしょう。 AndroidTestCase Android でユニットテストをするなら、ほぼ間違いなく使うであろうクラスです。 そのようなテストケースでは、すべてこのクラスを基底に作っていきます。 もう少し具体化して言うと、Contextに依存するすべてのテストはこのテストクラスを使うことで、イイカンジにテスト
Javaのモックアップフレームワーク「mockito」でリクエスト／セッションを再現する
しかし、開発推進セクションとしてリーダーを中心に「基本的には必須ですが、相談には乗ります」と伝えてきました。もちろん、こちらとしても妥協することはありますが、基本は書いてもらうように言い続けたことは良かったと思います。今ではテストケースは2,000ケース以上となり、毎日jenkinsからもallTestの結果が送られてくるようになったのですから。そんなやりとりをしていく中で、こんなFAQも生まれました。 Q：巨大なメソッドで1行だけ修正したのですが、そのメソッド内をすべてテストしないといけないの？ A：基本はテストしてください。 ただしトラブル対応など、どうしてもすぐにリリースしないといけない場合はその限りではありません。 結果的にこのようなFAQは、開発メンバーにJUnitの導入を受け入れてもらうために必要なことだったと思います。やはり、開発スピードを重視するチームにとって、やることが多
「テストデータを修正しました」に学ぶ - (define -ayalog '())
2014-01-29 「テストデータを修正しました」に学ぶ 開発 日記 先日こんなことがあった。僕「このテストデータを使って、テストしてください」 海の向こう「日本から提供されたテストデータを使うとエラーがでます。なので、テストデータを修正しました。これで正常に動作することを確認しました」 ふざけるなああああああああああ(涙— ぷろぐらみんぐしょしんしゃ (@ayato_p) 2014, 1月 27どうやらIT系の人たちに刺さりまくったようで1000RT Overという自己*1最高記録を更新しました。オフショア開発やっていると「わりとよくある」日常だと思う。僕も過去4年間のエンジニア生活の中で何度となく出会ってきた。その度に「オフショア開発やりたくないよー」って思うわけなんだけど。 何故こんなことが起こるのか 可能性としては以下のような感じでしょうか。 自分たちは正しいという絶対の自信を持
jenkins + prove で失敗したテストを並列しないで再テストする試み - soh335 memo
深淵な理由で（特に並列度をあげると）たまに落ちてしまうテストがあって、その度にあぁこれはたまに落ちちゃうやつなんですよねみたいな会話するのもいかがかと思っていた。 なので、落ちたテストがあった場合に並列しないで再度 prove してあげてそれでも落ちたらレポートするがいいかなぁと思ったのでこういう感じでやってみた。 JUNIT_NAME_MANGLE=none JUNIT_OUTPUT_FILE=output.xml prove -lvr -j5 --harness TAP::Harness::JUnit t JUNIT_OUTPUT_FILE は TAP::Harness::JUnit が生成する xml を指定する環境変数。 JUNIT_NAME_MANGLE に関しては TAP::Harness::JUnit - search.cpan.org に説明がある。 デフォルトだと hud
テストケースを動的に生成してJUnitで実行する | DevelopersIO
AWSチームに参画して2ヶ月ほど経ちました。ところが、AWSの構築などにはあまり関わらず、ひたすらAWSに関連するプロダクトの開発を行う毎日です。そんな折、ボスより次のようなリクエストをいただきました。 ユーザが参照できない情報について、参照できないことを検証して欲しい ・・・「出来ないことの検証」です。 「出来ることの検証」であれば、その例をテストケースとして記述してテストを実行すれば検証出来ます。しかし、出来ないことを証明することは非常に困難です。ただ、情報は有限なんで、総当たりにでもやればできるかもしれません。 ！？ システムのインフラは当然のようにAWSです。テストのためのリソースが足りなければ増やせばいいじゃないですか。時間がかかるならば並列化すればいいじゃないですか。テストの時だけ増やせばいいんです。 ならば、総当たりでテストしよう という方針になりました。そして、ブログのネタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
