IBM DeveloperIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
AssertJ / Fluent assertions for java
AssertJ Core site has moved to https://assertj.github.io/doc/ This site is still maintained for AssertJ modules (until their documentation is migrated) Rich and easy to use AssertJ provides a rich set of assertions, truly helpful error messages, improves test code readability and is designed to be super easy to use within your favorite IDE. Get started right away with the one minute starting guide
Java Day Tokyo 2014でテストのお話 - nekop's blog
Java Day Tokyo 2014で「Javaアプリケーション開発におけるテストとTDDの実践」というセッションを@t_wadaと@shuji_w6eと@nekopの3人共演でやりました。講演中はいっぱいいっぱいなのであまりまわりの状況がよく見えていなかったのですが、250人の部屋が満席立ち見という状態になっていたみたいです。ありがとうございます。 こんな大規模なイベントを参加費無料かつすばらしい設備の会場でやるというのはとてもすごいことだと思います。OracleさんのJavaに対する姿勢が見えますね。ありがとうございました。 自分は統合テスト自動化というトピックで、より本物に近い環境でテストすることの重要性とか、Arquillianｲｲﾖｰ、統合テストのコスト下げられるよー、楽しいよー、ってお話をしました。スライドは以下のURLで公開しています。 http://nekop.githu
プライベートフィールドに対するテスト | DevelopersIO
クラスメソッドの渡辺です。 弊社では業務時間内にブログを書くことが推奨されており、ネタも何でも良いということで、自動化やユニットテスト関連も投下していきます。今日は結構良く話題に出るプライベートフィールドに対するテストです。 オブジェクト指向プログラミングと可視性 オブジェクト指向プログラミングのひとつの特徴はカプセル化です。簡単に言えば、フィールド（情報）やメソッド（機能や操作）の公開範囲を可能な限り狭くすることで、安全にオブジェクトを扱うことができる、ということです。このため、古典的なJavaのコーディング標準では、次のように、「全てのフィールドをprivateに設定し、必要に応じてアクセサメソッドを定義すること」となっています。 public class Item { private String name; private int price; public String getN
リフレクションでprivateをテストしてみる - 日々常々
発端 [twitter:@meganii] さんのつぶやきが発端。不可視クラスってことは…privateクラスと無名クラス？これらをリフレクションで云々したこと無かったので、やってみました。 対象クラス package test.reflect; public class Target { public String publicMethod() { new Object() { String test() { return "AnonymousClassTest"; } }; return "Public"; } private String privateMethod() { return "Private"; } private static class PrivateStatic { String test() { return "PrivateStaticClassTest";
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
Free Web Hosting - Your Website need to be migrated
check Unlimited Number of Websites check Unlimited Email Accounts check Unlimited Bandwidth check 2X Processing Power & Memory check LiteSpeed Cache check WordPress Acceleration (LSCWP) check Cloudflare Protection check Github Integration check 24/7/365 Support check Easy Website Builder check 99.9% Uptime Guarantee check DNS Management check Unlimited MySQL Databases check 100 Subdomains check Un
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Arquillian