Unit test seharusnya menggunakan FIRST principles agar unit test memberikan nilai lebih dalam penggunaannya.  FIRST principles ini tertuang dalam buku Clean Code karangan Robert C. Martin.

First principles adalah singkatan dari :
1. Fast
2. Independent
3. Repeatable
4. Self-validating
5. Timely

1. FAST
Test harus berjalan dengan cepat.
Bila test berjalan dengan lambat, maka kita akan malas untuk menjalankan unit test. Bila kita malas untuk menjalankan test, maka kita tidak akan sering menemukan bug/error/code smell/design smell untuk diperbaiki. Dan pada akhirnya the software start to rotting!!!

2. INDEPENDENT
Test harus independent terhadap test lainnya.
Bila test tergantung dengan test lain dan terjadi error, maka proses diagnosis menjadi lebih sulit.

3. REPEATABLE
Test harus dapat dijalankan di environment apapun dan menghasilkan hasil yang sama setiap kali test dijalankan.
Bila test tidak menghasilkan behaviour yang sama pada environment yang berbeda, maka kita selalu memiliki alasan untuk mempertahankan diri bahwa program kita (bisa jadi) adalah benar.

4. SELF-VALIDATING
Test hanya boleh menghasilkan 1 dari 2 kondisi, yaitu sukses atau gagal.

5. TIMELY
Test code harus dibuat sebelum production code dibuat.

3. F.I.R.S.T
4. TDD on Three Index Cards

Ketika pertama kali mempelajari TDD, ada beberapa jargon yang menerangkan tentang TDD. Beberapa diantaranya adalah TDD cycle, Three laws of TDD, dan RED-GREEN-REFACTOR.

Setelah googling kesana dan kesini, akhirnya saya mendapat kesimpulan bahwa semua jargon-jargon itu menerangkan sesuatu yang sama persis.

Tetapi yang paling saya suka dari ketiga jargon itu adalah RED-GREEN-REFACTOR. Mengapa? karena dari namanya, saya langsung memahami pengertiannya.

Berikut adelah penjelasan singkat dari masing-masing jargon

TDD CYCLE

Jargon ini saya dapatkan dari buku Test Driven Development : By Example (Karangan Kent Beck)

THREE LAWS OF TDD

Jargon ini saya dapatkan dari buku Clean Code (Karangan Robert C. Martin)

First Law : You may not write production code until you have written a failing unit test.
Second Law : You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law : You may not write more production code than is sufficient to pass the currently failing test.

RED-GREEN-REFACTOR

Saya tidak tahu pasti darimana jargon ini, akan tetapi jargon ini sudah sangat terkenal untuk menjelaskan apa itu TDD.

Sudah beberapa tahun ini saya belajar dan bekerja dengan java. Pada awal saya belajar, saya mengutamakan penguasaan bahasa dan sertifikasi profesional. Setelah itu, fokus saya berubah pada penguasaan framework.
Saat ini fokus saya berubah lagi, tidak lagi pada penguasaan bahasa ataupun framework, melaikan belajar bagaimana bisa membuat code yang maintanable, clean code, sesuai prinsip OOD, pattern dan lain sebagainya.

Why? mmm, entah mengapa, saya juga bingung. Tapi yang pasti, fokus ini berubah karena ada insting bahwa good developer bukan hanya developer yang bisa menguasai bahasa atau framework secara 100%, tapi good developer adalah orang yang merasa  bahwa kode yang dia buat adalah bagian dari dirinya dan proses development adalah code craftmanship (ya, saya adalah artis yang sedang belajar).

Disini saya tidak mengatakan bahwa belajar framework adalah useless. Tidak. Tidak. Saya tidak mengatakan itu, tapi yang harus disadari adalah time curve belajar bahasa pemrograman ataupun framework relatif pendek. Dari pengalaman saya adalah sekita 2-3 minggu untuk mulai bisa bekerja dengan suatu framework.
Karena perubahan fokus belajar itulah, saya mulai mencari buku, referensi, blog, dsb. Ketika saya mempelajari referensi-referensi itu, timbul masalah baru. Bagaimana saya mempraktekkan semua yang telah saya pelajari?
Googling sana sini, akhirnya saya menemukan jawabannya : CODE KATA.

Untuk mengetahui apa itu code kata, anda bisa mulai dari sini dan sini. Point utama dalam code kata adalah practice!!!

Nb : Para master development seperti Robect C. Martin pun menggunakan code kata…..

Situs-situs yang bagus tentang code kata :
http://www.codekata.com/
http://katas.softwarecraftsmanship.org/
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
http://blog.objectmentor.com/articles/search?q=kata

TDD Cycle :

1. Add a little test.
2. Run all tests and fail.
3. Make a little change.
4. Run the tests and succeed.
5. Refactor.

Buku Test Driven Design By Example, Karangan Kent Beck (Chapter 1)

Sudah 3 tahun jadi developer java, tapi setiap hari semakin sadar kalo saya bodoh.
Beberapa sertifikasi java sudah saya dapat, tapi ternyata itu bukan jaminan bahwa kita benar-benar mengerti java.
Piuh
Satu yang saya sadar, meski kita terlibat dalam project java, belum tentu ilmu kita bertambah tiap hari.
Ok, mungkin ilmu kita bertambah ketika starting project (belajar framework, belajar konfigurasi, dll), but, ketika project sudah mulai berjalan, akan timbul hari-hari yang relatif monoton. Hari ini sama seperti kemarin, hanya domain masalah yang berbeda.
Ok ok ok, developer memang bisa menjadi matang dengan beberapa proses yang monoton, tapi satu yang saya rekomendasikan buat anda (dan terlebih buat saya sendiri) adalah kita meluangkan waktu tiap hari untuk mempelajari hal baru.
Contoh, hari ini saya telah belajar TDD, maka besok harus belajar refactoring. Lusa harus belajar DDD, dan selanjutnya.

Baru-baru ini saya harus mendebug bagian kode program yang dibuat oleh orang lain. Dan ini adalah pekerjaan yang sangat SUCK.Saya sama sekali TIDAK MEMILIKI KEBERANIAN untuk merubah kode-kode itu.
WHY??? ya, saya mendebug pasti dengan tujuan untuk menghilangkan BUG. Tapi bila kode program  yang harus saya debug itu tidak memiliki unit testnya, bagaimana saya bisa memastikan bahwa perubaahan yang saya buat justru tidak membuat bug baru???
Suck.

Salah satu cara paling mudah dalam mempelajari TDD adalah dengan berpartner / berpasangan dengan developer yang telah terbiasa dengan TDD. Akan tetapi bila tidak memungkinkan, kita dapat memahami konsep TDD dengan melihat screencast yang banyak terdapat di internet.

Beberapa screencast TDD yang mudah dipahami adalah :

1. http://agilesoftwaredevelopment.com/videos/test-driven-development-basic-tutorial
2. http://agilesoftwaredevelopment.com/videos/test-driven-development-mock-objects

Salah satu buku yang seharusnya menjadi bacaan wajib developer java adalah buku Effective Java karangan Joshua Bloch. Buku ini menjadi bacaan wajib karena buku ini mengajarkan penggunaan paling efektif dari bahasa pemrograman java.

Mengutip perkataan James Gosling tentang buku ini “I sure wish I had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.”

Pada edisi 2, buku ini memberikan 78 item cara bagaimana membuat pemrograman java menjadi lebih efektif, dimana ke 78 item itu terpecah menjadi 10 pokok permasalahan.

I. Creating and Destroying Objects

• Item 1: Consider static factory methods instead of constructors
• Item 2: Consider a builder when faced with many constructor parameters
• Item 3: Enforce the singleton property with a private constructor or an enum type
• Item 4: Enforce noninstantiability with a private constructor
• Item 5: Avoid creating unnecessary objects
• Item 6: Eliminate obsolete object references
• Item 7: Avoid finalizers

II. Methods Common to All Objects

• Item 8: Obey the general contract when overriding equals
• Item 9: Always override hashCode when you override equals
• Item 10: Always override toString
• Item 11: Override clone judiciously
• Item 12: Consider implementing Comparable

III. Classes and Interfaces

• Item 13: Minimize the accessibility of classes and members
• Item 14: In public classes, use accessor methods, not public fields
• Item 15: Minimize mutability
• Item 16: Favor composition over inheritance
• Item 17: Design and document for inheritance or else prohibit it
• Item 18: Prefer interfaces to abstract classes
• Item 19: Use interfaces only to define types
• Item 20: Prefer class hierarchies to tagged classes
• Item 21: Use function objects to represent strategies
• Item 22: Favor static member classes over nonstatic

IV. Generics

• Item 23: Don’t use raw types in new code
• Item 24: Eliminate unchecked warnings
• Item 25: Prefer lists to arrays
• Item 26: Favor generic types
• Item 27: Favor generic methods
• Item 28: Use bounded wildcards to increase API flexibility
• Item 29: Consider typesafe heterogeneous containers

V. Enums and Annotations

• Item 30: Use enums instead of int constants
• Item 31: Use instance fields instead of ordinals
• Item 32: Use EnumSet instead of bit fields
• Item 33: Use EnumMap instead of ordinal indexing
• Item 34: Emulate extensible enums with interfaces
• Item 35: Prefer annotations to naming patterns
• Item 36: Consistently use the Override annotation
• Item 37: Use marker interfaces to define types

VI. Methods

• Item 38: Check parameters for validity
• Item 39: Make defensive copies when needed
• Item 40: Design method signatures carefully
• Item 41: Use overloading judiciously
• Item 42: Use varargs judiciously
• Item 43: Return empty arrays or collections, not nulls
• Item 44: Write doc comments for all exposed API elements

VII. General Programming

• Item 45: Minimize the scope of local variables
• Item 46: Prefer for-each loops to traditional for loops
• Item 47: Know and use the libraries
• Item 48: Avoid float and double if exact answers are required
• Item 49: Prefer primitive types to boxed primitives
• Item 50: Avoid strings where other types are more appropriate
• Item 51: Beware the performance of string concatenation
• Item 52: Refer to objects by their interfaces
• Item 53: Prefer interfaces to reflection
• Item 54: Use native methods judiciously
• Item 55: Optimize judiciously
• Item 56: Adhere to generally accepted naming conventions

VIII. Exceptions

• Item 57: Use exceptions only for exceptional conditions
• Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
• Item 59: Avoid unnecessary use of checked exceptions
• Item 60: Favor the use of standard exceptions
• Item 61: Throw exceptions appropriate to the abstraction
• Item 62: Document all exceptions thrown by each method
• Item 63: Include failure-capture information in detail messages
• Item 64: Strive for failure atomicity
• Item 65: Don’t ignore exceptions

IX. Concurrency

• Item 66: Synchronize access to shared mutable data
• Item 67: Avoid excessive synchronization
• Item 68: Prefer executors and tasks to threads
• Item 69: Prefer concurrency utilities to wait and notify
• Item 70: Document thread safety
• Item 71: Use lazy initialization judiciously
• Item 72: Don’t depend on the thread scheduler
• Item 73: Avoid thread groups

X. Serialization

• Item 74: Implement Serializable judiciously
• Item 75: Consider using a custom serialized form
• Item 76: Write readObject methods defensively
• Item 77: For instance control, prefer enum types to readResolve
• Item 78: Consider serialization proxies instead of serialized instances

• Buku Effective Java 2nd edition, karangan Joshua Bloch (chapter 1)
• Amazon.com

Dalam suatu software development project, sering kita memulai project itu dengan gambaran yang jelas akan apa yang akan kita kerjakan. Akan tetapi seiring dengan berjalannya proses development, sering kita mengalami bahwa software yang kita buat semakin sulit untuk dimaintain (ditambah fitur baru, diubah fitur yang telah ada). The software start to rotting.

Design smells – The odors of rotting software

Kita mengetahui bahwa software yang kita buat mulai mengalami rotting ketika salah satu (atau lebih) hal-hal berikut terjadi :

1. Rigidity
2. Fragility
3. Opacity
4. Viscosity
5. Needless Complexity
6. Needless Repetition
7. Immobility

1. Rigidity

Rigidity adalah kecenderungan suatu software untuk sulit dirubah. Suatu design adalah rigid bila sebuah perubahan pada suatu modul menyebabkan banyak perubahan pada modul-modul yang lain.

2. Fragility

Fragility adalah kecenderungan suatu software untuk error di banyak tempat ketika suatu perubahan dibuat.

3. Opacity

Opacity adalah kecenderungan suatu software untuk sulit dipahami. Kode program yang berkembang seiring waktu biasanya akan semakin sulit dipahami ketika kode program itu dibaca.

4. Viscosity

Terdapat 2 bentuk viscosity, yaitu : Software viscosity dan Environment viscosity.

Software viscosity. Ketika software developer dihadapkan pada suatu perubahan, sering developer memiliki beberapa cara untuk melakukan perubahan itu. Ada cara yang tetap mempertahankan design yang telah dipakai untuk software itu (design preserving), ada pula cara yang tidak memperhatikan design yang dipakai untuk software itu (hack). Ketika cara design-preserving lebih sulit untuk dilakukan daripada hack, viscosity dari software itu tinggi. Dangan kata lain, lebih mudah untuk melakukan hal yang salah, daripada hal yang benar.

Environment viscosity. Environment viscosity terjadi ketika development environment terlalu lambat dan tidak efisien. Sebagai contoh, ketika waktu compile software terlalu lama, maka developer akan tergoda untuk membuat perubahan yang menyebabkan proses compile tidak lama, meski perubahan yang dilakukannya tidak memperhatikan design.

5. Needless Complexity

Needless complexity adalah design smell yang terjadi ketika design kita mengandung elemen yang tidak berguna pada saat ini.

Dalam suatu project, sering kita mengantisipasi suatu perubahan kebutuhan dengan memberi fasilitas untuk menyelesaikannya (dalam sisi design). Pada awalnya hal ini terlihat sebagai sesuatu yang cerdas, akan tetapi dengan berjalannya waktu, efek yang timbul justru sebaliknya.

Dengan menambah design untuk antisipasi perubahan kebutuhan di masa datang, maka ada bagian design yang tidak berguna dan ini membuat software semakin komplek dan semakin sulit untuk dimengerti.

6. Needless Repetition

Dalam suatu team, programmer A harus menyelesaikan suatu masalah, kemudian ia mencari contoh kode di dalam project yang sedang ia kerjakan yang sesuai untuk permasalahannya, kemudian mengcopy-paste kode itu dan memodifikasi kode itu agar sesuai dengan permasalahannya.

Yang tidak diketahui oleh programmer A bahwa kode itu adalah kode buatan programmer B dimana programmer B juga meng-copy paste dari bagian lain dari project (dan juga memodifikasinya). Bagaimana bila ternyata kode yang di-copy paste oleh programmer B ternyata adalah hasil copy-paste programmer C dari programmer D????

Dari ilustrasi ini terlihat bahwa kode yang di-copy paste ada di dalam project berulang kali dalam bentuk yang berbeda. Duplicate code terjadi, dan abstraction dilupakan. Apa yang terjadi seandainya kebutuhan akan code yang di-copy paste itu berubah? Seluruh Kode yang di-copy paste oleh programmer A,B,C,D juga harus berubah.

Hal ini berbeda ketika abstraction dipegang oleh programmer dan copy-paste dihindari sedapat mungkin. Ketika ada perubahan kebutuhan, maka bagian kode program yang harus berubah hanya satu, bukannya di setiap kode yang di-copy paste oleh masih-masing programmer.

7. Immobility

Sebuah design adalah immobile ketika suatu bagian design dari suatu sistem berguna untuk sistem lain, tetapi usaha dan resiko untuk memisahkan bagian itu dari sistem aslinya terlalu besar.

Agile Principles, Patterns, and Practices in C# ; by Martin C. Robert dan Martin Micah. (Chapter 7)

Contoh fine grained :

.....
int panjang = 20;
int lebar = 10;
int tinggi = 5;
balok.setPanjang(panjang);
balok.setLebar(lebar);
balok.setTinggi(tinggi);
long volume = balok.hitungVolume();
.....

Contoh coarse grained :

.....
int panjang = 20;
int lebar = 10;
int tinggi = 5;
long volume = balok.hitungVolume(panjang, lebar, tinggi);
.....