private void sayName(String name){
    // compiler akan memberitahu jika variable ini sudah di deklaraskikan
    String name = "Hello world";
    System.out.println(name)
}

contoh lain shadowing variable adalah variable antara inner class dan outerclass

class OuterClass {
    String name = "outer name";

    Class InnerClass {
        String name = "inner name"

        private void print(String name){
            System.out.println(name)
            System.out.println(this.name);
            System.out.println(OutterClass.this.name);
        }
    }
}

Jika kita lihat disana sebenarnya pada Java ada shadowing variable tapi untuk menghilangkan ke ambiguan ini pada Java ada keyword this , yang mana ini membuat kita lebih mudah membaca program di Java, terus bagaimana shadowing variable di Rust?

Shadowing variable pada Rust kurang lebih agak mirip-mirip dengan shadowing variable di JavaScript, jadi kita bisa declare variable dengan nama yang sama untuk tipe data juga boleh beda, yang perlu di ingat adalah value terakhir yang akan digunakan adalah value terakhir yang di deklarasikan contoh

fn main(){
    let a = 10;
    let a = String::from("hello");
    println!("{}", a);
}

Mungkin kita akan mikir ulang, ini kenapa perlu ada shadowing karena kalau keseringan dipakai bikin pusing bacanya, yup pertanyaan ini benar jika di implemntasikan di Java tapi jika di Rust mungkin akan menjadi keunggulan kalau dipikir, contohnya

fn increment(num: i32) -> i32 {
    return num + 1;
}

fn main() {
    let input_str = "42";
    let input_parsed = input_str.parse::<i32>().unwrap();
    let input_incremented = increment(input_parsed);
    let input_final = input_incremented + 3;
    println!("{}", input_final);
}

kalau dilihat diatas kita bakalan sibuk mikirin nama variable untuk setiap proses, coba kita lihat ketika kita meleverage manfaat shadowing

fn increment(num: i32) -> i32 {
    return num + 1;
}

fn main() {
    let input = "42";

    let input = input.parse::<i32>().unwrap();
    let input = increment(input);
    let input = input + 3;

    println!("{}", input);
}

lebih clean bukan dan kita bisa lebih fokus ke proses apa yang sebenarnya terjadi, namum perlu di note shadowing ini kaya pedang bermata dua kalau tidak wise menggunakannya ya pusing juga.

Membuat User

ssh root@your-server-ip
adduser newuser
usermod -aG sudo newuser
su - newuser #Test user

Setup SSH

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub newuser@your-server-ip
ssh newuser@your-server-ip

Harden SSH (Dikonfigruasi pada VPS)

sudo vim /etc/ssh/sshd_config

# ubah line berikut
PermitRootLogin no # Disable root login
PasswordAuthentication no  # Disable password based auth

# Restart SSH dan Test SSH dari local
sudo systemctl restart ssh
ssh newuser@your-server-ip

Install Uncomplicated Firewall (UFW)

sudo apt install ufw

sudo ufw allow OpenSSH    # SSH
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

# enable ufw dan cek status
sudo ufw enable
sudo ufw status

Setup Fail2ban

# Install Fail2Ban
sudo apt install fail2ban

# Copy default ke local untuk dirubah nantinya
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo vim /etc/fail2ban/jail.local

# Pastikan configurasi ssh untuk akeses dikonfigurasi sebagai berikut 
# [sshd]
# enabled = true
# port = 22 # sesuaikan dengan port ssh di vps
# maxretry = 5
# bantime = 3600

# Restart Fail2Ban service
sudo systemctl restart fail2ban

# Check Fail2Ban status
sudo fail2ban-client status
sudo fail2ban-client status sshd

Ini dikarenakan ada dependency issue dari testing-library/react@13.4.0 yang mana library ini memerlukan React versi 18 sedangkan project yang akan dibuat menggunakan React 19. Secara dokumentasi pada React.js 19 pembuatan project dengan menggunakan npx create-react-app sudah tidak direkomendasikan dan menyaranakan penggunakan React menggunakan framework seperti Next.js atau Remix. Jika masih ingin membuat project React tanpa menggunakan framework beberapa cara yang dapat dilakukan

Install menggunakan Vite

npm create vite@latest frontend -- --template react atau
npm create vite@latest frontend -- --template react-ts (React dengan Typescript)

• Partisi Vertikal

• Partisi Horizontal

Partisi table dapat dilakukan dengan beberapa pendekatan

• Partisi by range (contohnya berdasarkan tanggal atau id)

• Partisi by List (umutnya digunakan unutk nilai diskrit)

• Partisi by hash (menggunakan nilai hash namun hashingnya harus konsisten)

anggaplah terdapat sebuah table bernama student pada sebuah database yang berisi 10.000.000 baris yang strukturnya sebagai berikut

insert into students(name, grade)  
select  
    random_string(10) as name,  
    floor(random() * 100) as grade  
from  
    generate_series(0, 10000000);

kemudian akan dilaukan partisi berdasarkan nilai pelajar, yang mana partisi ini dibagi menjadi 5 dengan kelipatan nilai 20

untuk membuat table dengan partisi, sama halnya dengan pembuatan table pada umunya yang membedakan adalah penambahan keyword partition by.

CREATE TABLE students_grade_partitions  
(  
    id    serial,  
    name  text,  
    grade int not null  
) partition by range (grade);

perlu diingat jika menambahkan primary key maka kolom grade harus ditambahkan sebagai komposite. jika tidak maka akan menghasilkan error

[0A000] ERROR: unique constraint on partitioned table must include all partitioning columns Detail: PRIMARY KEY constraint on table "students_grade_partitions" lacks column "grade" which is part of the partition key.

Setelah table utama dibuat, proses selanjutnya pembuatan table partisi sebanyak total paritsi yang diinginkan

CREATE TABLE students_grade0020 (like students_grade_partitions including indexes );  
CREATE TABLE students_grade2140 (like students_grade_partitions including indexes );  
CREATE TABLE students_grade4160 (like students_grade_partitions including indexes );  
CREATE TABLE students_grade6180 (like students_grade_partitions including indexes );  
CREATE TABLE students_grade81100 (like students_grade_partitions including indexes);

command including indexes ini sangat penting ketika membuat paritisi karena partisi bergantung dengan index, jadi jika ada perubahan index pada tabel utama akan berpengaruh juga pada tabel partisi. Table partisi yang telah dibuat perlu di assign ke table utama. Perlu diingat untuk nilai to sifatnya adalah exclusive

ALTER TABLE students_grade_partitions attach PARTITION students_grade0020 FOR VALUES FROM (0) TO (21);  
ALTER TABLE students_grade_partitions attach PARTITION students_grade2140 FOR VALUES FROM (21) TO (41);  
ALTER TABLE students_grade_partitions attach PARTITION students_grade4160 FOR VALUES FROM (41) TO (61);  
ALTER TABLE students_grade_partitions attach PARTITION students_grade6180 FOR VALUES FROM (61) TO (81);  
ALTER TABLE students_grade_partitions attach PARTITION students_grade81100 FOR VALUES FROM (81) TO (100);

Jika dilihat lihat secara visual table partisi tersebut akan menjadi bagian dari table utama

Partisi vs non partisi

untuk hasil perbandingan query table dengan partisi dan non partisi adalah sebagai berikut.

Query range

explain analyze select * from students_grade_partitions where grade > 40 and grade < 61;

/* OUTPUT
Seq Scan on students_grade4160 students_grade_partitions  (cost=0.00..41441.50 rows=1803866 width=14) (actual time=0.133..140.940 rows=1802569 loops=1)  
  Filter: ((grade > 41) AND (grade < 60))  
  Rows Removed by Filter: 199798  
Planning Time: 0.302 ms  
Execution Time: 186.098 ms
*/

explain analyze select * from students where grade > 41 and grade < 60;
/* OUTPUT
Bitmap Heap Scan on students  (cost=24437.02..108267.03 rows=1791667 width=14) (actual time=70.474..524.556 rows=1802569 loops=1)  
  Recheck Cond: ((grade > 41) AND (grade < 60))  
  Heap Blocks: exact=56955  
  ->  Bitmap Index Scan on students_grade  (cost=0.00..23989.11 rows=1791667 width=0) (actual time=63.083..63.083 rows=1802569 loops=1)  
        Index Cond: ((grade > 41) AND (grade < 60))  
Planning Time: 0.638 ms  
JIT:  
  Functions: 2  
"  Options: Inlining false, Optimization false, Expressions true, Deforming true"  
"  Timing: Generation 1.441 ms, Inlining 0.000 ms, Optimization 0.000 ms, Emission 0.000 ms, Total 1.441 ms"  
Execution Time: 574.170 ms
*/

Perbandingan eksekusi waktu diatas cukup jelas data yang dipartisi menghasilkan eksekusi lebih cepat karena query rangenya grade > 40 and grade < 61, Postgress hanya perlu melakukan scaning index pada satu partisi students_grade4160 dan tidak mengalami overhead dari membangun bitmap. Sedangkan query kedua karena data yang di index cukup besar maka akan dibuat bitmap yang menyebabkan query jadi lambat.

Apa yang terjadi jika kita menscan seluruh partisi dengan menggunakan query untuk grade yang lebih dari 5?

explain analyze select * from students_grade_partitions where grade > 7;
/* OUTPUT
Append  (cost=0.00..227967.39 rows=9202076 width=14) (actual time=9.562..1413.924 rows=9199930 loops=1)  
  ->  Seq Scan on students_grade0020 students_grade_partitions_1  (cost=0.00..38217.45 rows=1302431 width=14) (actual time=9.561..224.284 rows=1300285 loops=1)  
        Filter: (grade > 7)  
        Rows Removed by Filter: 800071  
  ->  Seq Scan on students_grade2140 students_grade_partitions_2  (cost=0.00..36408.10 rows=2000968 width=14) (actual time=0.196..211.621 rows=2000968 loops=1)  
        Filter: (grade > 7)  
  ->  Seq Scan on students_grade4160 students_grade_partitions_3  (cost=0.00..36435.59 rows=2002367 width=14) (actual time=0.149..196.123 rows=2002367 loops=1)  
        Filter: (grade > 7)  
  ->  Seq Scan on students_grade6180 students_grade_partitions_4  (cost=0.00..36358.74 rows=1998219 width=14) (actual time=0.110..179.299 rows=1998219 loops=1)  
        Filter: (grade > 7)  
  ->  Seq Scan on students_grade81100 students_grade_partitions_5  (cost=0.00..34537.14 rows=1898091 width=14) (actual time=0.105..170.764 rows=1898091 loops=1)  
        Filter: (grade > 7)  
Planning Time: 6.056 ms  
JIT:  
  Functions: 10  
"  Options: Inlining false, Optimization false, Expressions true, Deforming true"  
"  Timing: Generation 1.445 ms, Inlining 0.000 ms, Optimization 1.203 ms, Emission 8.386 ms, Total 11.034 ms"  
Execution Time: 1634.274 ms
*/

explain analyze select * from students where grade > 7;
/* OUTPUT
Seq Scan on students  (cost=0.00..181955.01 rows=9201001 width=14) (actual time=4.328..845.234 rows=9199930 loops=1)  
  Filter: (grade > 7)  
  Rows Removed by Filter: 800071  
Planning Time: 0.280 ms  
JIT:  
  Functions: 2  
"  Options: Inlining false, Optimization false, Expressions true, Deforming true"  
"  Timing: Generation 0.538 ms, Inlining 0.000 ms, Optimization 0.253 ms, Emission 3.852 ms, Total 4.642 ms"  
Execution Time: 1062.563 ms
*/

Kita bisa lihat sekarang query kedua lebih cepat tanpa partisi, hal ini dikarenakan pada query tersebut ketika dilakukan proses pencarian keseluruh partisi akan ada prosess append setelah dilakukan pencarian per partisi, sedangkan jika tanpa partisi hal yang perlu dilakukan hanya squential scan index saja tidak perlu ada proses append karena tidak terpartisi hal ini menyebabkan query kedua lebih cepat.

Ukuran data

Apakah dengan menggunakan partisi memori akan menjadi lebih kecil sebenarnya tidak terlalu signifikan

Kesimpulan

secara umum manfaat partisi akan berasa jika pencarian hanya dilakukan pada satu partisi saja akan terasa sekali manfaatnya karena pencarian menjadi lebih kecil apalgi jika kolom pencarian sudah di indexing. Perlu di ingat enable_partition_pruning harus selalu dalam kondisi on, jika tidak maka percuma dilakukan peartisi karena pencarian akan dilakukan disemua partisi yang menyebabkan query jadi lebih lama.

Umunya ketika membuat table dengan primary key secara default kolom yang menjadi primary key akan dibuatkan indexnya menggunakan B-Tree (Balance Tree)

Contoh : Anggaplah kita terdapat sebuah database (menggunakan postgres) yang memiliki table employees yang berisi 1000000 recrod dengan stuktur data sebagai berikut

explain analyze select * from emplyees where name = 'Zs';
/* OUTPUT
Gather  (cost=1000.00..11310.94 rows=6 width=10) (actual time=3.088..47.719 rows=25 loops=1)  
  Workers Planned: 2  
  Workers Launched: 2  
  ->  Parallel Seq Scan on employees  (cost=0.00..10310.34 rows=2 width=10) (actual time=1.931..18.586 rows=8 loops=3)  
        Filter: (name = 'Zs'::text)  
        Rows Removed by Filter: 333325  
Planning Time: 0.364 ms  
Execution Time: 47.785 ms
*/


explain analyze select * from employees where id = 100;
/* OUTPUT
Index Scan using employees_pkey on employees  (cost=0.42..8.44 rows=1 width=10) (actual time=0.093..0.095 rows=1 loops=1)  
  Index Cond: (id = 100)  
Planning Time: 0.237 ms  
Execution Time: 0.178 ms
*/

Kita bisa melihat dari dua query diatas menghasilkan waktu eksekusi yang sangat berbeda kenapa bisa seperti itu?. Untuk query pertama pencarian bedasarkan kolumn name tidak menggunakan indexing, sehingga pencarian dilakukan dengan melakukan pengecekan pada setiap baris pada kolom name pada table employees.

Sedangkan pada query kedua, pencarian menggunakan id (ini di indexing) proses pencarian dilakukan dengan menggunakan scanning index yang sudah dibuat sehingga tidak perlu melakukan pengecekan pada setiap baris pada table employees.

Bagaimana membuat index dan prosesnya pada Postgres?

Untuk membuat index perlu menjalankan query

CREATE INDEX nama_index on nama_table(nama_kolumn);

/* menambahakna index untuk kolom name
CREATE INDEX EPLOYEE_NAME on employees(name);
*/

Proses yang terjadi dibalik CREATE INDEX adalah Postgres akan pembacaan data secara menyeluruh terlebih dahulu kemudian Postgress akan membuat B-Tree berdasarkan kolom tersebut, sehingga waktu yand dibutuhkan untuk pembuatan index berdasarkan banyaknya data yang ada pada table tersebut. Kita bisa melihat hasil perbedaan performa query pertama setelah di indexing

explain analyze select * from employees where name = 'Zs';

/*
Bitmap Heap Scan on employees  (cost=4.47..27.93 rows=6 width=10) (actual time=0.326..0.363 rows=25 loops=1)  
  Recheck Cond: (name = 'Zs'::text)  
  Heap Blocks: exact=25  
  ->  Bitmap Index Scan on employee_name  (cost=0.00..4.47 rows=6 width=0) (actual time=0.318..0.318 rows=25 loops=1)  
        Index Cond: (name = 'Zs'::text)  
Planning Time: 4.501 ms  
Execution Time: 0.391 ms
*/

Pembuatan index dengan penggunaan CREATE INDEX terlihat sangat menjanjikan namun kenapa query berikut ini tidak melakukan index scanning?

explain analyze select * from employees where name like '%Zs'

/* OUTPUT
Gather  (cost=1000.00..11319.34 rows=90 width=10) (actual time=0.425..44.853 rows=266 loops=1)  
  Workers Planned: 2  
  Workers Launched: 2  
  ->  Parallel Seq Scan on employees  (cost=0.00..10310.34 rows=38 width=10) (actual time=0.203..22.971 rows=89 loops=3)  
        Filter: (name ~~ '%Zs'::text)  
        Rows Removed by Filter: 333245  
Planning Time: 0.384 ms  
Execution Time: 44.896 ms
*/

Hal ini bisa terjadi karena secara default index yang dibuat pada Postgress mengguakan B-Tree yang mana struktur data ini di design untuk melakukan perbandingan secara terurut seperti =, >, <, >=, <= dan LIKE tanpa pengunaan wildcard di depan yang menyebabkan Postgress tidak tahu bagaimana cara menghandle query tersebut pada B-tree, sehingga Postgress harus melakukan scanning secara sekuensial pada setiap baris pada table employees.

Agar query menggunakan wildcard dapat berjalan dengan lebih baik hal yang perlu dilakukan adalah merubah indexingnya menggunakan trigam (Trigraph). Trigram adalah sekelompok tiga karakter berurutan yang diambil dari sebuah kata, hal ini memungkinkan untuk mengukur kemiripan dua buah kata (https://www.postgresql.org/docs/current/pgtrgm.html)

CREATE EXTENSION pg_trgm;  
create INDEX trgm_employee_name on employees USING gin (name gin_trgm_ops);

explain analyze select * from employees where name like '%Za';
/* OUTPUT
Bitmap Heap Scan on employees  (cost=17.56..342.82 rows=90 width=10) (actual time=0.478..2.449 rows=230 loops=1)  
  Recheck Cond: (name ~~ '%Za'::text)  
  Rows Removed by Index Recheck: 463  
  Heap Blocks: exact=641  
  ->  Bitmap Index Scan on trgm_employee_name  (cost=0.00..17.53 rows=90 width=0) (actual time=0.288..0.288 rows=693 loops=1)  
        Index Cond: (name ~~ '%Za'::text)  
Planning Time: 3.182 ms  
Execution Time: 2.543 ms
*/

Anggaplah terdapat sebuah POJO class Product.java

@Entity
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class Product {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private int id;
  private String name;
  private int price;
  private int quantity;

  private String imageLocation;

  public void updateProduct(Product updatedProduct) {
    this.name = updatedProduct.name;
    this.price = updatedProduct.price;
    this.quantity = updatedProduct.quantity;
  }

  public ProductDTO convertToDTO() {
    return ProductDTO.builder()
        .id(this.id)
        .name(this.name)
        .price(this.price)
        .quantity(this.quantity)
        .imageUrl(this.imageLocation)
        .build();
  }
}

untuk dua method di atas updateProduct dan convertToDTO sudah dibuat unit testnya namun ketika cek coverage reportnya, cukup mengesankan.

Coveragenya tidak sampai 50%, untuk mengatasi problem coverage ini ada beberapa cara yang bisa dilakukan

1. Mengexclude class model tersebut dari coverage report dari project

2. Mengexclude generated code dari Lombok

Yang nomor 1 kurang disarankan karena kadang class model juga memiliki bisnis prosessnya sendiri, tidak hanya setter, getter, dan antek-anteknya saja.

Pada Lombok versi 1.14 diperkenalkan fitur lombok configuration system yang mana developer dapat mengkonfigurasi fitur lombok pada proyek atau workspace, biasanya dilakukan dengan menambahkan lombok.config pada root project, untuk apa saja yang bisa dikonfigurasi bisa dilihat di official Lombok projectnya https://projectlombok.org/features/configuration.

Dari semua pilihan konfigurasi pada official websitenya, ada satu configurasi yang membatu untuk mengexclude generated code yaitu lombok.addLombokGeneratedAnnotation = true , dengan menambahakan configurasi ini semua code yang digenerate oleh Lombok akan memiliki annotation @Generated , dengan adanya annotation ini Jacoco akan mengabaikan code terkait pada coverage.

@Generated
public int hashCode() {
    int PRIME = true;
    int result = 1;
    result = result * 59 + this.getId();
    result = result * 59 + this.getPrice();
    result = result * 59 + this.getQuantity();
    Object $name = this.getName();
    result = result * 59 + ($name == null ? 43 : $name.hashCode());
    Object $imageLocation = this.getImageLocation();
    result = result * 59 + ($imageLocation == null ? 43 : $imageLocation.hashCode());
    return result;
 }

tanpa configurasi lombok.addLombokGeneratedAnnotation = true

public int hashCode() {
    int PRIME = true;
    int result = 1;
    result = result * 59 + this.getId();
    result = result * 59 + this.getPrice();
    result = result * 59 + this.getQuantity();
    Object $name = this.getName();
    result = result * 59 + ($name == null ? 43 : $name.hashCode());
    Object $imageLocation = this.getImageLocation();
    result = result * 59 + ($imageLocation == null ? 43 : $imageLocation.hashCode());
    return result;
}

Coverage result pada Product.java setelah menambahkan lombok.addLombokGeneratedAnnotation = true pada lombok.config

Anggaplah kita memiliki sebuah kontroler question yang akan mengembalikan semua list pertanyaan yang mana pada kontroler tersebut memiliki sebuah service question. Berikut adalah contoh classnya

import java.util.List;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping(path = "/questions")
public class QuestionController {
  @Autowired
  QuestionService questionService;

  @GetMapping(produces = "application/json")
  public List<Question> fecthAllQuestions(){
    return questionService.getAll();
  }

}

Bagaimana sebaiknya unit test yang tepat untuk class kontroler ini? Umunya untuk melakukan unit test untuk kontroler adalah dengan melakukan simulasi seolah-olah ada request dari Internet yang melakukan request get pada routing /questions yang kemudian aplikasi akan mengirim response list object question. Bearti apakah perlu untuk mengirim request dari brower?, tentu tidak, ide ini bisa disimpan ketika membutuhkan E2E test.

Pada Springboot terdapat class MockMvc dan WebMvcTest yang digunakan untuk menguji dan mensimulasikan perilaku aplikasi tanpa perlu mendeploy aplikasi ke server. dan memungkinkan untuk mengirim permintaan HTTP ke aplikasi tanpa browser dan memeriksa respons yang dihasilkan, serta melakukan verifikasi perilaku kontroler yang dibuat.

Mari kita mulai langkah demi langkah untuk membuat unit testnya, dimulai dari line kode dibawah sebagai dasar pembuatan unit testnya

@WebMvcTest(QuestionController.class)
class QuestionControllerTest {

    @Mock
  QuestionService questionService;

  @Autowired
  private MockMvc mockMvc;

  @Test
  void fetchShouldReturnAllQuestionsList() throws Exception {
    this.mockMvc.perform(get("/questions"))
        .andExpect(status().isOk());
  }
}

Pada kode diatas @WebMvcTest(QuestionController.class) Anotasi ini digunakan untuk pengujian fungsionalitas pada kontroler tanpa harus menginisiai seluruh konteks aplikasi, sehingga pengujian menjadi lebih fokus dan cepat, simplenya class ini digunakan untuk menjalankan class controller kita, dan mockMvc anggaplah seperti service yang akan digunakan untuk mengirim request ke dummy controller yang sudah dibuat. Pada method test fetchShouldReturnAllQuestionsList kita membuat unit test mockMvc untuk mengirim request GET ke kontroller yang sudah dibuat sebelumnya yang mana berhapakan mendapatakn response OK (HTTP status code 200). Test diatas masih kurang komprehensif karena hanya melakukan checking pada http status code tapi tidak dengan response bodynya.

Pada case sperti ini akan lebih simple ketika kita memiliki sample response dalam file berupa .json dibanding membuat object pada unit testnya disamping lebih mudah, maintenancenya pun akan lebih simple ketika jumlah unit testnya terus bertambah. Buatlah sebuah file berupa sampleQuestionResponse.json pada test/resources/fixtures/question/

[
  {
    "id": "65d8d8e73b429a2b1dacbb37",
    "type": "SINGLE",
    "question": "1 + 1 =",
    "options": [
      {
        "a": "0"
      },
      {
        "b": "1"
      },
      {
        "c": "2"
      },
      {
        "d": "3"
      }
    ]
  }
]

kemudian unit test sebelumnya bisa diupdate degan menambahkan resource path dan ObjectMapper untuk melakukan mapping dari json menjadi object.

@WebMvcTest(QuestionController.class)
class QuestionControllerTest {

  @Autowired
  MockMvc mockMvc;

  @MockBean
  private QuestionService questionService;

  @Value("classpath:fixtures/question/sampleQuestionResponse.json")
  private Resource responseSample;

  ObjectMapper mapper = new ObjectMapper();

  @Test
  void fetchShouldReturnAllQuestionsList() throws Exception {
    mockMvc.perform(get("/questions"))
        .andExpect(status().isOk()).andExpect(content().json("[]"));
  }
}

untuk implementasinya diperlukan untuk melakukan load json fixture tersebut, dan menampungnya pada sebuah variable, tidak lupa untuk melakukan mock pada questionService dengan mengconvert json yang sudah dibaca menjadi object karena jika tidak di mock, secara default service tersebut akan akan megembalikan list kosong.

@Test
void fetchShouldReturnAllQuestionsList() throws Exception {
    String sampleResponse = responseSample.getContentAsString(StandardCharsets.UTF_8);
    TypeFactory typeFactory = mapper.getTypeFactory();
    List<Question> items = mapper.readValue(sampleResponse, typeFactory.constructCollectionType(List.class, Question.class));
    when(questionService.getAll()).thenReturn(items);

    mockMvc.perform(get("/questions"))
        .andExpect(status().isOk()).andExpect(content().json(sampleResponse));
 }

java.time.LocalDate seperti namanya LocalDate hanya dapat digunakan untuk menyimpan data berupa tanggal (Tahun, bulan dan hari) (yyyy-mm-dd) dan harus diingat tipe data ini sifatnya immutable.

berikut adalah contoh penggunaannya.

// untuk membuat date format
LocalDate date = LocalDate.of(2007, 12, 3);
// untuk menampikan tanggal sekarang
LocalDate now = LocalDate.now();

// membandingkan
LocalDate date1 = LocalDate.of(2007, 12, 3);
LocalDate date2 = LocalDate.of(2007, 12, 4);

date1.isBefore(date2); // => true
date1.isAfter(date2); // => false

//instance ini juga memiliki setter getternya sendiri
now.getDayOfMoth(); // => mengembalikan tanggal
now.addDays(3); // => menambahkan hari ini + 3

java.time.LocalDateTime seperti namanya LocalDateTime ini seperti Tanggal yang membedakannya tipe data ini dapat menyimpan waktu dari jam, menit hingga detik.

Berikut adalah contoh penggunnaannya

// membuat instance
LocalDateTime dateTime = LocalDateTime.of(2024, 1, 14, 20, 10, 01);
// untuk menampikan tanggal dan waktu sekarang
LocalDateTime now = LocalDateTime.now();
// konversi LocalDate ke LocalDateTime
LocalDate datenow = LocalDate.of(2024, 01, 14);
LocalDateTime dateTimeToday = datenow.at(10, 10, 10);
dateTimeToday.toString() // => 2024-01-14T10:10:10

Melakukan formatting pada kedua instance

Untuk format date time juga dapat dilakukan pembuatan instance dari dan ke string.

LocalDateTime datetime = LocalDateTime.of(2024, 01, 14, 10, 0, 0);
LocalDateTime parsed = LocalDateTime.parse("2024-01-14T10:00:00");

dateTime.equal(parsed); // => true

// dibuat dengan formatter
DateTimeFormatter parser = DateTimeFormatter.ofPattern("dd/MM/yyyy");
LocalDate date = LocalDate.parse("14-01-2024", parser);

DateFormatter printer = DateTimeFormatter.ofPattern("MMMM d, yyyy");
printer.format(date); // => "January 14, 2024

//bisa juga dilakukan degan custom
LocalDate now = LocalDate.now();
DateFormatter printer = DateTimeFormatter.ofPattern("'sekarang adalah hari 'EEEE d, yyyy");

printer.format(now);