新しいソフトウェア開発技法へチャレンジできるか? ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング(XP)という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
Mercurialをemacsやzsh、global, その他の設定ファイルの管理だけでなく、ソースコードの管理にも本格的に使うようになったこともあり、ブランチやマージの機能も頻繁に使うようになってきた。 このへんの機能を使ってて思うのはやはりCVSやSubversionに比べてブランチの作成や切り替え、マージ等の操作が簡単に行えるということ。これはGitについても同じことが言えるが、Gitのコマンドラインインタフェースは個人的にはかなり微妙。 ブランチの一覧を表示 narazuya@bokkko% hg branches diff3 30:1946a2e61b7e default 23:fd1771eddd50 (inactive) 0.04 22:3549817de2ba (inactive) 0.03 12:9a49ae230cf6 (inactive) narazuya@bokkk
Landscape トップページ | < 前の日 2006-03-27 2006-03-28 次の日 2006-03-29 > Landscape - エンジニアのメモ 2006-03-28 トランクやブランチなどのバージョン管理用語の意味 当サイト内を Google 検索できます * トランクやブランチなどのバージョン管理用語の意味この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [VSS] [Subversion] バージョン管理システムで使われる用語の意味のメモ。主に CVS、Subversion、VSS (Visual SourceSafe) で使われる用語が対象。 - リポジトリ repositoryバージョン管理の履歴が保存されているところ。リポジトリのバックアップだけはしっかり取っておこう。 - ツリー treeリポジトリにある一連のファイルをまと
H/Wの信号等を確実に繰り返しリードする必要がある場合などにVolatile宣言した変数を使用します。 コンパイラのプライオリティ(優先度)が高い場合は、最初に1回だけ信号を内部CPUレジスタにリードして、2回目以降はレジスタに読み込んだ1回目のデータをリードデータとして使用してしまう事があるので、それを防ぐ(確実にH/W(メモリ)などをアクセスするようにする)ために、Volatile宣言を使用します。 例)H/W信号がONするまで待ち、その後に何かを行う処理、の場合。 long *signal; signal = 0x1000;/*0x1000番地の信号*/ while(*singal == 0)/*信号がON(0以外)するまで待つ*/ ; /*信号がONしてから行う処理*/ : : 上記の例のプログラムの場合、 最初に1回信号をリードし、その結果を内部CPUレジスタなどに保存し、 2回
自動で単体テスト、ステートメントカバレッジ、そしてテストケースレビューで、適当な関数を作って、適当な単体テストの条件を作ってみた。この中で「指定日が元旦から何日目かを返答する関数(daycount)」についてもう少しきちんとテストしてみようかと。 == ブラックボックステストの観点 ブラックボックステストなので、基本的には「指定日が元旦からの日数」が正しく計算できるか、という仕様からテストケース・テスト条件を洗い出す。でもまずは関数インターフェースを眺めてみる。 int daycount( int year, int month, int day ); 引数は、 year(西暦) month(月) day(日) の3つ。西暦はここでは「1900年~2100年」という範囲に限定する、という(かくれ)仕様。月は「1月~12月」、日は「1日~31日」である。これは自明な仕様とでもいうのだろうか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く