Teamwork & TDD — Sprint 2 Blog Azahra

Dalam mata kuliah PPL ini, saya berkelompok dengan teman-teman satu angkatan saya yaitu Aldi, Fadli, Hasan, Rayza, dan Yudhis. Mengerjakan sebuah proyek dalam jangka waktu tertentu seorang diri tentu bukanlah hal yang mudah, tetapi mengerjakan proyek tersebut dengan sebuah tim juga membawa tantangannya tersendiri. Bekerja dalam tim bukan merupakan sesuatu yang baru bagi saya karena sebelumnya beberapa mata kuliah sudah pernah mengeluarkan tugas yang wajib dikerjakan dalam kelompok. Walaupun begitu, bekerja dalam tim di mata kuliah PPL memiliki kesan yang berbeda karena jangka waktunya yang panjang dan beban kerjanya yang lebih besar dibanding kerja kelompok di mata kuliah sebelumnya.

Hal-hal di bawah ini adalah pengalaman saya bekerja dalam sebuah tim, dimulai dari pekerjaan secara teknis seperti version control dan git flow yang kami gunakan sampai penerapan agile. Selain itu, akan saya bahas juga penerapan metodologi TDD yang sejauh ini telah saya lakukan di mata kuliah PPL ini.

Git

Version control yang digunakan oleh mata kuliah PPL adalah Git. Git memungkinkan setiap developer yang terlibat dalam sebuah proyek untuk memiliki salinan dari code yang terdapat di repositori utama (master) dan membuat percabangan agar pengembangan dapat dilakukan secara paralel dan perubahan code dapat terkontrol dengan rapi.

Ilustrasi git flow yang digunakan dalam mata kuliah PPL

Mata kuliah PPL menerapkan git flow yang dirancang dengan menggabungkan standar industri dengan kemudahan pelaksanaan perkuliahan. Cabang-cabang yang terdapat pada git flow PPL adalah:

1. Master : cabang utama terkait production yang siap dipakai oleh user.
2. Staging : cabang utama terkait pengembangan yang mengandung semua hasil pekerjaan anggota tim yang digunakan untuk sprint review.
3. User Story : cabang untuk mengimplementasi sebuah user story.
4. Hotfix : cabang dari master yang digunakan untuk memperbaiki bug yang ditemukan di cabang master.
5. Coldfix : cabang yang digunakan untuk melakukan rollback ketika product owner menolak salah satu atau semua user story saat sprint review.

Pada penggunaannya, saya menggunakan beberapa perintah git, seperti:

1. git pull : mengambil perubahan yang terjadi pada remote repository ke local repository.
2. git push : melakukan perubahan yang terjadi pada local repository ke remote repository.
3. git clone : membuat salinan dari remote repository di local repository.
4. git merge : menggabungkan perubahan yang ada di dua cabang.
5. git rebase : memodifikasi riwayat commit yang sudah ada.
6. git revert : mengembalikan kondisi code ke commit sebelumnya.
7. git stash : menghilangkan perubahan code untuk sementara dan memunculkannya kembali ketika sudah melakukan perubahan lain.
8. git remote : menghubungkan local repository dengan remote repository.
9. git checkout : berpindah ke cabang lain atau membuat cabang baru.
10. git branch : mengetahui cabang mana saja yang ada.

Pada sprint 1, kelompok kami sempat melakukan kesalahan pada pembuatan cabang. Kami membuat cabang sesuai dengan task yang kami ambil sehingga terdapat beberapa cabang untuk sebuah user story. Awalnya kami melakukan hal tersebut agar kegiatan code review dapat dilakukan dengan lebih mudah dengan mengetahui siapa yang menulis code tersebut. Setelah berkonsultasi dengan dosen, kami mendapatkan penjelasan bahwa pembuatan cabang sampai pada level user story dilakukan untuk meningkatkan kerja sama tim kami. Dengan meningkatnya merge conflict yang kemungkinan besar akan terjadi, karena banyak anggota yang bekerja pada satu cabang yang sama, maka kami akan meningkatkan komunikasi satu sama lain untuk mengatasi conflict tersebut.

Code review kami lakukan di dalam merge request ke cabang staging dari cabang user story yang telah dibuat. Anggota yang melakukan code review kami usahakan merupakan anggota yang tidak mengerjakan task dari user story tersebut. Pada saat melakukan merge, kami melakukan commit squash agar riwayat commit dapat dilihat dengan lebih mudah.

Agile

Mata kuliah PPL menggunakan metodologi Scrum dalam proses pengembangannya. Scrum adalah subset dari Agile yang merupakan metodologi pengembangan perangkat lunak yang bersifat iteratif di mana requirements dapat berubah-ubah sehingga tim pengembang juga harus bersifat fleksibel.

Nilai inti dari Agile tercatat dalam Agile Manifesto yang terdiri dari 4 poin, yaitu:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Kami berusaha menerapkan ke-empat nilai tersebut dalam pengembangan perangkat lunak yang kami lakukan di mata kuliah PPL.

Kami menjaga interaksi kami sebagai tim dengan melakukan daily meeting setiap hari Selasa dan Jumat untuk berkomunikasi mengenai perkembangan dan kendala apa yang kami temukan. Dokumentasi yang kami lakukan bisa dibilang cukup dengan adanya PBI yang diberikan oleh product owner kami di awal perkuliahan dimulai. Setelah mendapat daftar PBI, kami melakukan sprint planning agar kami dapat segera mengimplementasikan requirements yang sudah ditulis oleh product owner kami. Dalam perjalanannya, kami terkadang menghubungi product owner kami untuk memastikan apakah ada requirements yang berubah. Ketika diperlukan, kami memberikan saran kepada product owner mengenai bagaimana sebaiknya sebuah fitur diimplementasikan. Dengan begitu, kami berusaha untuk merespon setiap perubahan yang diberikan oleh product owner agar semua hal yang kami lakukan sesuai dengan tujuan yang ingin dicapai oleh product owner.

Prinsip Agile yang tertulis di situs resmi Agile

Selain empat nilai di atas, Agile juga memiliki 12 prinsip yang harus diterapkan dalam penggunaannya:

1. Satisfy customers through early and continuous delivery of valuable work.

Perkuliahan PPL sudah menjadwalkan sprint review yang dilakukan setiap 2 minggu sekali sehingga tim dapat memberikan hasil pekerjaan yang dapat digunakan secara rutin.

2. Welcome changing requirements for the customer’s competitive advantage.

Tim kami berusaha untuk menjaga komunikasi dengan product owner untuk memastikan PBI masih sesuai dan kami tidak menolak perubahan yang diberikan oleh product owner.

3. Deliver working software frequently.

Prinsip ini sudah diterapkan juga dengan diadakannya sprint review setiap 2 minggu sekali.

4. Work together with business people daily throughout the project.

Hal ini tidak mudah untuk dilakukan dalam perkuliahan PPL karena product owner kami tidak bisa bertemu dengan kami secara rutin setiap harinya. Tetapi kami masih bisa berhubungan via media sosial jika ada hal-hal yang ingin ditanyakan atau disampaikan kepada product owner kami.

5. Build projects around motivated individuals.

Kami sebagai tim saling menyemangati satu sama lain ketika ada kesempatan karena kami bersama-sama ingin menyempurnakan proyek yang sedang kami kerjakan.

6. Convey information with face-to-face conversation.

Komunikasi antar anggota tim pengembang dapat dijaga dengan adanya daily meeting yang diadakan 2–3 hari sekali. Untuk komunikasi dengan product owner, memang tidak mungkin rasanya untuk bertemu secara langsung dengan sering.

7. Working software is the primary measure of progress.

Perkuliahan PPL menetapkan definition of done yang menandakan kapan suatu PBI dapat dibilang selesai. Semakin banyak PBI yang selesai sesuai estimasi pada sprint planning maka semakin baik kerja tim kami.

8. Promote sustainable development.

Pengembangan yang berkelanjutan dapat dicapai dengan pemecahan task menjadi ukuran yang sesuai sehingga tidak ada anggota tim yang merasa bahwa ada task yang terlalu besar sehingga sudah melelahkan di awal sprint.

9. Give attention to technical excellence and good design.

Desain program yang baik dan penulisan code yang rapi akan memudahkan pengembangan dalam jangka waktu lama. Kami masih berusaha menerapkan prinsip ini walaupun memang tidak mudah.

10. Simplicity is essential.

Kami mengutamakan kebutuhan-kebutuhan yang diprioritaskan oleh product owner kami terlebih dahulu untuk dikerjakan. Hal-hal yang sekiranya merupakan fitur tambahan tidak kami kerjakan.

11. Self-organizing teams.

Kelompok kami berusaha untuk menyeimbangkan dan mengambil task sesuai dengan kemampuan dan kemauan belajar yang kami miliki masing-masing. Kami juga saling membantu satu sama lain jika kami menemukan kendala.

12. Teams reflect on how to become more effective.

Pada sprint retrospective pertama, kelompok kami menyadari bahwa waktu yang kami luangkan untuk PPL masih kurang. Kami menemukan solusi untuk masalah ini yaitu dengan mengadakan sesi “mengoding bersama” di Fasilkom secara rutin agar kami sama-sama termotivasi untuk menyelesaikan task.

Test Driven Development

Perkuliahan PPL menerapkan metodologi Test Driven Development (TDD) dalam pengembangan proyeknya. TDD mewajibkan para pengembang untuk membuat test terlebih dahulu, baru kemudian membuat implementasi code. Hal ini bertujuan agar kami terbiasa untuk memikirkan secara matang spesifikasi input-output dari program yang akan ditulis dan membantu proses implementasi code menjadi lebih terarah.

Prinsip RED, GREEN, REFACTOR diterapkan dalam PPL ini.

Siklus TDD; RED, GREEN, REFACTOR

Tahap RED berarti test harus dibuat terlebih dahulu sebelum implementasi code yang sebenarnya. Pada tahap ini, test pasti akan gagal karena memang belum ada implementasi code yang bisa membuat test sukses. Tahap GREEN merupakan tahap implementasi code yang pada akhirnya akan membuat semua test yang telah dibuat sebelumnya sukses. Tahap REFACTOR adalah tahap perubahan implementasi yang dapat membuat program berjalan dengan lebih efektif ataupun ada perubahan lain yang ingin dilakukan. Pada tahap REFACTOR, harus dipastikan konsistensi behaviour program terjaga dengan membuat test tetap sukses.

Penerapan TDD dilakukan dengan membuat unit test dalam pengembangan proyek kami. Prinsip-prinsip dalam pembuatan unit test dikenal dengan prinsip F.I.R.S.T, yaitu:

1. Fast : test seharusnya dijalankan dengan cepat. Hal ini masih sulit untuk dilakukan karena saya masih belajar bagaimana menjalankan test yang paling efisien.
2. Isolated : test harus dapat mengidentifikasi sebuah kesalahan yang spesifik dan tidak memiliki dependensi. Sejauh ini saya menulis unit test dengan memikirkan skenario mana saja yang akan menyebabkan error pada program.
3. Repeatable : test harus dapat dijalankan secara berkali-kali tanpa bergantung pada sebuah state awal atau meninggalkan state akhir. Test yang dijalankan oleh kelompok kami hanya mencakup implementasi internal program kami yang tidak membutuhkan environment luar sehingga dapat dilakukan berulang-ulang.
4. Self-validating : test harus memiliki output yang jelas mengenai kesuksesan atau kegagalannya sehingga pengembang tidak perlu membaca banyak file untuk melihat apakah test tersebut sukses atau tidak. Unit test yang saya buat sejauh ini mudah diidentifikasi kesuksesannya sehingga tidak perlu membaca banyak file.
5. Timely : test harus dibuat pada waktu yang tepat, yaitu sebelum implementasi code. Siklus RED, GREEN, REFACTOR yang diterapkan oleh perkuliahan PPL membuat saya belajar untuk terbiasa membuat unit test terlebih dahulu sebelum implementasi code.

Berikut adalah contoh unit test yang saya buat untuk komponen pagination dengan menggunakan framework React.

it('should have n pagination items when maxPage is n where n is less than 6', () => {
    const pagination = shallow(
       <Pagination
          maxPage={1}
       />
    );
expect(pagination.find(PaginationItem).length).toBe(1);
});
it('should contain 2 as the second item if pageNumber is less than maxPage-3 or less than 3', () => {
    const pagination = shallow(
       <Pagination
          maxPage={50} pageNumber={48}
       />
    );    
 expect(pagination.find(PaginationItem).get(1).props.itemNumber).toBe(2);
});
it('should contain 3 as the third item if pageNumber is less than 4', () => {
    const pagination = shallow(
       <Pagination
          maxPage={50} pageNumber={2}
       />
    );
expect(pagination.find(PaginationItem).get(2).props.itemNumber).toBe(3);
});

TDD sangat terasa manfaatnya ketika bekerja dalam tim, terutama ketika terjadi conflict atau setelah melakukan merge dengan cabang lain. Ketika saya ingin menambahkan implementasi fitur yang berhubungan dengan pekerjaan teman sekelompok saya yang lain, saya menemukan kegagalan test dari code yang dibuat oleh teman saya. Dengan adanya deskripsi dari test tersebut, saya memahami behaviour program apa yang ingin dijaga oleh teman saya. Hal ini meminimalisir proses debugging yang dapat memakan waktu banyak jika tidak diatasi di awal.

class ImageServiceTests(TestCase):

    def setUp(self):
        upload_from_string = Mock(return_value=1)
        blob = Mock(upload_from_string=Mock(side_effect=upload_from_string))
        get_bucket = Mock(blob=Mock(side_effect=blob))
        image_service_mock = Mock(get_bucket=Mock(side_effect=get_bucket))
        self.image_service = ImageService(image_service_mock)

    def test_upload_image_success(self):
        random_byte = os.urandom(11)
        self.image_service.upload_image(random_byte, 'tes', '200x200', '400x400', '800x800')
        picture_count = Picture.objects.all().count()
        self.assertEqual(picture_count, 1)

Pendekatan yang dilakukan pada unit test di back end adalah dengan membuat mock dari fungsi yang diberikan oleh servis yang saya gunakan. Untuk implementasi fitur ini, saya menggunakan servis Google Cloud. Pada bagian setUp, saya menginisiasi mock fungsi yang dibutuhkan agar unit test dapat berjalan.

Perbedaan yang saya rasakan dalam membuat unit test jika dibandingkan dengan front end adalah perlunya pembuatan mock karena menggunakan servis eksternal. Sejauh ini, task front end yang saya lakukan hanya me-render komponen yang sudah dibuat dan akan dites.