DEV Community: Prayoch Rujira

บันทึกเกี่ยวกับ test coverage

Prayoch Rujira — Tue, 25 Mar 2025 14:16:38 +0000

สวัสดีครับ วันนี่มีมิตรสหายมาสอบถามเกี่ยวกับ test coverage ในภาษา Go เลยเอามาเขียนบล็อกเก็บไว้ด้วย

ในภาษา Go เราสามารถรันเทสด้วยคำสั่งนี้พร้อมกับ option -cover เพื่อดู code coverage ได้

> go test ./calculator -cover
ok      coverage/calculator     0.359s  coverage: 100.0% of statements

และยังสามารถสร้างเป็น HTML report ได้ ด้วยคำสั่ง

> go test ./... -covermode=atomic -coverprofile=coverage.out
> go tool cover -html=coverage.out -o coverage.html

เมือเปิดดูไฟล์ HTML ที่ได้จะสามารถดูได้ว่าบรรทัดไหนบ้างที่ถูกใช้งานจากการรัน unit test

สำหรับผู้ที่ใช้ VSCode ก็สามารถเปิด code coverage ได้เช่นกัน ด้วยการกด cmd(ctrl) + shift + p แล้วเลือกคำสั่งนี้

อย่างไรก็ตาม แม้เราจะมี code coverage ที่ 100% แล้วก็ไม่ได้แปลว่า unit test นั้นครบทุก case แล้ว
ตัวอย่างเช่น function นี้

func Divide(a, b int) (float64, error) {
    if b == 0 {
        return 0, fmt.Errorf("division by zero")
    }
    return float64(a) / float64(b), nil
}

กับ unit test

func TestDivide(t *testing.T) {
    tests := []struct {
        name        string
        a, b        int
        expected    float64
        expectError bool
    }{
        {"valid division", 6, 2, 3.0, false},
        {"division by zero", 6, 0, 0, true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result, err := Divide(tt.a, tt.b)
            if tt.expectError {
                if err == nil {
                    t.Error("Divide() expected error but got none")
                }
                return
            }
            if err != nil {
                t.Errorf("Divide() unexpected error: %v", err)
                return
            }
            if result != tt.expected {
                t.Errorf("Divide(%d, %d) = %f; want %f", tt.a, tt.b, result, tt.expected)
            }
        })
    }
}

เมื่อเรา run test ก็จะได้ 100% แน่นอนเพราะว่า test ของเราวิ่งเข้าครบทุกเงื่อนไข

แต่ test coverage ไม่สามารถเตือนเราได้ว่า input เป็นเลขลบได้นะ! ดังนั้น เราควรจะเพิ่ม case เลขติดลบเข้าไปด้วย

func TestDivide(t *testing.T) {
    tests := []struct {
        name        string
        a, b        int
        expected    float64
        expectError bool
    }{
        {"valid division", 6, 2, 3.0, false},
        {"division by zero", 6, 0, 0, true},
        {"negative numbers", -6, 2, -3.0, false},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result, err := Divide(tt.a, tt.b)
            if tt.expectError {
                if err == nil {
                    t.Error("Divide() expected error but got none")
                }
                return
            }
            if err != nil {
                t.Errorf("Divide() unexpected error: %v", err)
                return
            }
            if result != tt.expected {
                t.Errorf("Divide(%d, %d) = %f; want %f", tt.a, tt.b, result, tt.expected)
            }
        })
    }
}

เพราะฉะนั้น Code coverage ไม่เท่ากับ Test case coverage นะครับ

เพื่อป้องกันปัญหานี้การช่วยกันออกแบบ test case จึ่งมีความสำคัญ ลองทำ peer review โดยให้เพื่อนในทีม หรือ QA หรือ Product มาช่วยให้คำแนะนำก็ได้ แน่นอนว่าไม่ได้ให้มารีวิวโค้ด แต่ให้มาช่วยดู data ที่จะ test นั้นถูกต้อง เหมาะสม หรือไม่

หรือสมัยนี้สามารถใช้ AI เข้ามาช่วยวิเคราะห์ให้ได้เลยว่า test นั้นครบทุก edge case แล้วหรือยัง จะได้ออกมาเพียบ

        // Basic cases
        {"positive numbers", 6, 2, 3.0, false},
        {"negative numbers", -6, 2, -3.0, false},
        {"both negative", -6, -2, 3.0, false},
        {"numerator negative", -6, 2, -3.0, false},
        {"denominator negative", 6, -2, -3.0, false},

        // Zero cases
        {"division by zero", 6, 0, 0, true},
        {"zero numerator", 0, 5, 0.0, false},
        {"zero denominator", 5, 0, 0, true},
        {"both zero", 0, 0, 0, true},

        // One cases
        {"divide by one", 5, 1, 5.0, false},
        {"one by number", 1, 5, 0.2, false},
        {"one by one", 1, 1, 1.0, false},

        // Large numbers
        {"large positive", 1000000, 1000, 1000.0, false},
        {"large negative", -1000000, 1000, -1000.0, false},

        // Decimal results
        {"decimal result", 5, 2, 2.5, false},
        {"small decimal", 1, 3, 0.3333333333333333, false},

        // Edge cases
        {"max int32", 2147483647, 1, 2147483647.0, false},
        {"min int32", -2147483648, 1, -2147483648.0, false},
        {"max by max", 2147483647, 2147483647, 1.0, false},
        {"min by min", -2147483648, -2147483648, 1.0, false},

หรือจะไปให้ไกลกว่านั้น ก็ลองใช้เทคนิคอื่นๆพวก monkey test หรือ permutation test เข้ามาช่วยในการทำการทดสอบอีกระดับก็ได้ครับ ลองศึกษาดูจาก link ต่อไปนี้ก่อนก็ได้
https://www.geeksforgeeks.org/monkey-software-testing/
https://www.youtube.com/watch?v=8hQG7QlcLBk&ab_channel=GopherAcademy

Code coverage เป็นเครื่องมือที่มีประโยชน์มากในการพัฒนา software น่าเสียดายมากนะครับถ้าเอามาใช้เป็นแค่ quality gate เฉยๆ แต่ระหว่างทางเราไม่ได้เใช้ประโยชน์อะไรจากมันเลย

ลองเอามาใช้เป็นเครื่องมือทำให้การเขียน code ของเราสนุกมากขึ้นดูนะครับ

ทำความรู้จักกับ Meta Programming ใน Typescript

Prayoch Rujira — Mon, 05 Aug 2024 13:37:48 +0000

ก่อนอื่นเลย เราไปดูความหมายของ Meta programming จากใน wikipedia กันก่อน

Metaprogramming is a computer programming technique in which computer programs have the ability to treat other programs as their data. It means that a program can be designed to read, generate, analyse, or transform other programs, and even modify itself, while running.

แปลเองแล้วงง ลองให้ AI แปลดูซิ

Metaprogramming คือ เทคนิคในการเขียนโปรแกรมคอมพิวเตอร์ ซึ่งโปรแกรมสามารถจัดการกับโปรแกรมอื่น ๆ เหมือนข้อมูลของตัวเองได้ นั่นหมายถึงโปรแกรมสามารถออกแบบให้สามารถอ่าน สร้าง วิเคราะห์ หรือแปลงโปรแกรมอื่น ๆ และ ในบางกรณี สามารถปรับเปลี่ยนตัวเองขณะที่กำลังทำงานได้

ไม่ได้ช่วยเท่าไหร่เลย ผมลองอธิบายแบบบ้านๆดีกว่า
อย่างเวลาเราเขียนโปรแกรม เราก็จะประกาศตัวแปร หรือ function หรือ class ขึ้นมาเพื่อแก้ปัญหาอะไรสักอย่าง ในภาษาอย่าง Java หรือ Typescript ก็ถือเป็น object ประเภทหนึ่ง เราสามารถเข้าถึงข้อมูลบางอย่างได้ เช่น ชื่อ หรือถ้าฟังก์ชั่นก็จะดู input arguments ได้ เป็นต้น ซึ่งการเข้าถึงข้อมูลพวกนี้เรียกว่า metadata ก็เลยเป็นที่มาของ meta programming นี่แหละครับ

ยกตัวอย่างที่เราพอได้ใช้กันอยู่บ้าง เช่นการใช้ Object.hasOwnProperty()

เราสามารถที่จะเรียกดูรายชื่อ proterty ใน object ได้ด้วยการใช้ Object.keys

เข้าถึง property descriptor ด้วย Object.getOwnPerpertyDescriptor()

แก้ไขข้อกำหนดบางอย่างของตัว property ด้วย Object.defineProperty() อย่างเช่น ไม่อนุญาตให้แก้ไข

ลองเล่นกับ Decorator
ปกติแล้ว เราจะเป็นผู้ใช้งาน decorator กันซะมากกว่า ในหลายๆ framework เช่น Angular (แล้วเราก็เรียกมันว่า magic 😂)
ซึ่ง magic ที่ว่านี่ก็คือการใช้ประโยชน์จากการเข้าถึง meta data ได้นั่นแหละ

ลองมาดูหน้าตาของ decorator ใน TypeScript กัน ก่อนอื่นต้องรู้ก่อนว่าจะเอา decorator ไปวางไว้ที่ไหน เช่น class หรือ method

เอาง่ายๆก็ method ก่อน สมมติว่าเราจะสร้าง decorator ชื่อ log

วิธีใช้งานก็เอาไปวางบนหัว method แบบนี้

แน่นอนว่าตัว decorator ยังไม่ได้ทำอะไรเลย ดังนั้นเรามาดูกันต่อว่าทำอะไรกับมันได้บ้าง

สมมติว่า เราอยากจะทำการ log ทุกครั้งที่มีการเรียก method เราก็จะต้องทำการ decorate ก่อน ที่จะเรียก method จริงๆ
ที่นี้จะทำได้ยังไง ก็ผ่านตัว descriptor นั่นแหละ หน้าตามันก็คล้ายๆกับที่เล่าไปในตอนแรก
ใน descriptor มันจะมี property ตัวนึงชื่อ value ให้เราสามารถย่ำยีได้ตามใจชอบ ดังนั้น เราก็จะสร้าง function มาครอบของเดิม เพื่อให้มัน log ก่อน แล้วค่อยไปเรียกตัว method จริงๆ

ลองใช้งานดู ก็จะพบว่า จะมีการ log ทุกครั้งที่เรียกฟังก์ชั่น

แน่นอนว่า เราสามารถ เข้าถึงได้มากกว่าชื่อ functtion จะ log input arguments ก็ทำได้เช่นกัน

ที่นี้ก้ไม่ต้องคอยใส่ log เข้าไปทุก method แล้ว

อันนี้ก็ตัวอย่างที่เราเอาไปใช้ได้นะครับ เรื่อง metaprogramming ยังมีให้ศึกษาอีกเยอะมากเลย เป็นเครื่องมืออีกอันที่หยิบมาใช้ทำให้ชีวิตดีขึ้นได้ครับ ทำให้เข้าใจมากขึ้นเวลาไปใช้ framework ต่างๆด้วย ว่า magic แต่ละอันมันมาได้ยังไงด้วย 😎

จบไว้ประมาณนี้ก่อนะครับ ถ้ามีโอกาสจะมาเล่าเคสที่ซับซ้อนมากขึ้นอีกนิด

ทำ Software ไม่ได้มีแต่การปั่น Feature หรอกนะ

Prayoch Rujira — Mon, 20 Feb 2023 14:43:05 +0000

สวัสดีครับ เนื่องจากวันที่ 19 กุมภาพันธ์ 2566 ที่ผ่านมา พี่ปุ๋ยชวนไป(โดนฆ่า)พูดที่งาน National coding day จัดโดยสมาคมโปรแกรมเมอร์ไทย ที่ Bitec

เนื้อหาไม่ได้มีอะไรมาก เป็นการพูดคุยเกี่ยวกับเรื่องที่พบเจอได้ทั่วๆไปในการพัฒนา Software จนมันกลายเป็น meme ที่เอามาล้อกันสนุกสนาน แต่น้ำตามันตกอยู่ข้างใน

แน่นอนว่ากว่าผมจะรู้ว่าต้องพูดอะไร ก็ตอนที่ขึ้นเวทีไปแล้วนั่นเอง

แต่นั่นไม่ใช่ประเด็น จนต้องเอามาเขียน ที่ผมอยากจะเขึยนก็คือ ตอนปิดท้ายผมรู้สึกว่าตัวเองพูดรวบรัดไปหน่อย รู้สึกว่าสื่อสารออกไปได้ไม่ครบถ้วน เลยมาเรียบเรียงขยายความใหม่ น่าจะดีกว่า

เริ่มที่รูปนี้ จากใน Slide นั่นแหละ

คำถามคือ เราปล่อยให้ Bug มันขยายร่างขึ้นไปเรื่อยๆได้ยังไง
หรือผมลองตั้งคำถามใหม่
เราตั้งใจปล่อยให้บั๊กมันโตขึ้นเรื่อยๆหรือเปล่า?
มี Developer คนไหนตั้งใจ commit code ที่เป็น Bug เข้าระบบบ้าง
มี Tester คนไหนตั้งใจเขียน test case ที่ไม่มีวันทดสอบผ่านบ้าง
มี Designer คนไหน ตั้งใจสร้างของที่มันทำจริงๆไม่ได้ ใส่เข้าไปใน Figma บ้าง
มี Infra คนไหน ตั้งใจวางขั้นตอนให้มัน deploy ยากๆบ้าง
มี User คนไหน ตั้งใจให้ requirement ที่ไม่มีวันทำได้จริงบ้าง
และ อื่นๆอีกมากมาย

ผมคิดว่าจริงๆแล้ว ก็ไม่มีใครอยากทำร้ายกันหรอก ทุกคนก็อยากทำสิ่งดีๆทั้งนั้น ถ้างั้นแล้ว ปัญหามันมาจากอะไรล่ะ

ผมเดาว่า เป็นเพราะ ทุกคนมีเป้าหมายที่แตกต่างกัน เมื่อต่างคนต่างมุ่งหมายที่จะกระทำเป้าหมายของตัวเองให้สำเร็จเท่านั้น

ซึ่งมันเป็นเป้าหมายเดียวกันกับ software ที่กำลังทำกันอยู่หรือไม่?

ทำไมบั๊กมันถึงเติบโตขึ้นได้เรื่อยๆ สาเหตุหนึ่ง ก็เพราะว่าเรามี deadline ที่จะต้องทำ feature ทั้งหมดให้เสร็จตามที่ commit ไว้
ดังนั้น หลายๆครั้ง เราก็เลือกที่จะละเลยเรืองบางเรื่องไปก่อน เพื่อที่จะส่งมอบงานได้ทันเวลา
แล้วการต้องส่งมอบให้ได้ทันเวลา โดยที่ระบบมีปัญหา ใช้งานไม่ได มันเป็นเป้าหมายของใครกันล่ะ? ไม่น่ามีนะ
และเราก็ได้เรียนรู้ครั้งแล้วครั้งเล่าว่าธรรมชาติของการทำ Software มันไม่ได้เป้นแบบนั้น

ผมคิดว่า DevOps หรือ practice หลายๆตัวมันก็เกิดมาจากจุดนี้แหละ นั่นคือ ไม่ว่าคุณจะอยู่ตรงไหนของการทำ Software คุณจะต้องตระหนักรู้ถึงการที่ software ของคุณน่ะ มันจะถูกเอาไป Operate อย่างไร เราต้องทำอะไรหรือเตรียมตัวอย่างไรเพื่อ support สิ่งนั้น แล้ว practice หรือ tools ต่างๆ ค่อยตามมา

ขอให้สนุกกับการทำ Software มีความสุขทั้งฝั่งผู้ใช้งาน และฝั่งผู้พัฒนา ครับ

บันทึกการ Refactor

Prayoch Rujira — Wed, 25 May 2022 15:39:59 +0000

ในช่วงเดือนที่ผ่านมา ผมมีโอกาสได้เข้าไปช่วยเหลือให้คำแนะนำเกี่ยวกับการ Refactor ให้กับทีมที่กำลังทำแอปตัวหนึ่งมา เลยเอามาบันทึกและแบ่งปันไว้ตรงนี้ครับ

โดยโจทย์ที่ได้เจอก็คือ Code ถูกเขียนมาสักระยะแล้ว ประมาณ 3-4 เดือน โดยที่ไม่ได้มีการ Apply Design principles ใดๆเลย เนื่องจาก ต้องเผาให้ทันส่งนั่นเอง

ดังนั้น code smell ที่จะได้เจอแน่ๆ ก็คือ God class หรือ class ที่มันใหญ่มากๆ มีการทำงานหลายๆอย่างอยู่ข้างในนั้น บางที่ก็เรียก Monster class หรือ Kaiju class นะ อันนี้ก็แล้วแต่จะสรรหามาเรียกกัน แต่โดยรวมแล้วไม่ต่างกัน คืือมันร้ายกาจมาก เวลามันโมโหขึ้นมาก็อาจจะทำให้โปรเจคล่มได้เลยนะ

ยกตัวอย่างให้เห็นภาพ ตอนแรกที่เราเริ่มทำแอป เพื่อจะแยกส่วนแสดงผมกับส่วนของการประมวลผลหรือควบคุม UI ออกจากกัน ก็อาจจะมี View กับ ViewModel คู่กันแบบ 1:1 ใช่ไหมครับ และในเวลาต่อมา เราก็จะเริ่มเพิ่มfeature ที่ 2,3,4 เข้าไปเรื่อยๆ ในช่วงแรก มันยังเล็กๆอยู่ เราอาจจะยังไม่เห็นปัญหามากนัก เราจะเอาของใส่ใว้ตรงไหนล่ะ ก็ ViewModel ตัวเดิมนั่นไง ต่อมาเราก็เพิ่ม View ขึ้นมาอีกอันนึง แต่ feature มันก็ใกล้ๆกันนะ เราก็เอา feature ของ view ที่สองเอามาใส่กับ ViewModel ตัวเดิม แล้วเราก็ทำอย่างนี้ไปเรื่อยๆๆ หลังจากนั้น พอมีตรงไหนที่อยากจะ reuse feature ใน viewmodel ก็เอาไปเรียกใช้ได้เลย ทำให้ ViewModel ตัวเดียว อาจจะมีการเรียกใช้จากทุกหน้าในแอปก็เป็นได้

ซึ่งมันก็ดูจะสะดวกสบายดี เอาทุกๆอย่าง รวมไว้ใน class ก้อนเดียว เวลาเรียกใช้ก็ง่ายๆเลย ปัญหามันคืออะไรล่ะ

คำถามคือ มันทำให้งานของเรายากขึ้นเรื่อยๆหรือเปล่า?

งานของโปรแกรมเมอร์คืออออ
1.อ่านโค้ด
กับ 2.เขียน(แก้)โค้ด

เราทำข้อ 1 เพื่อหาจุดที่เราจะต้องแก้แล้วถึงทำข้อ 2 เพื่อให้ software ของเรามันเป็นไปตาม Requirement ถูกมั้ยครับ

ไอ้ตัว God class เนื่องจากมีการทำงานที่อัดแน่นอยู่ข้างในตัวมัน ดังนั้นสิ่งที่ตามมาก็คือปริมาณของโค้ดที่เราต้องอ่าน ซึ่งมันสามารถทำคอมโบกับ code smell อีกตัวที่ชื่อ long method ได้อีก ก้คือ method ที่ยาววววว มากๆ อาจจะเกิน 10-20 บรรทัดได้ และยังมีโอกาสเจอตัวอื่นๆได้อีกเพียบ

ยิ่งปริมาณโค้ดเยอะ ก็ยิ่งใช้เวลานานในการทำความเข้าใจ และเมื่อเวลาผ่านไป เราจะใช้เวลาอ่านโค้ดนานกว่าเขียนโค้ดมากขึ้นไปเรื่อยๆ และนี่ก็คือสาเหตุหนึ่งที่ทำไม productivity ของเหล่าโปรแกรมเมอร์มันลดลงๆ

ปัญหาต่อมาคือ แก้ไปแล้วรู้ได้ยังไงว่ามันทำงานถูก

การเกิด God class ส่วนหนึ่งเกิดจากการที่เราไม่มี unit test
เพราะถ้าเราเขียน unit test ไว้ตั้งแต่เนิ่นๆ เราจะรู้สึกได้ไวมากๆ ว่า class มันเริ่มมีปัญหา มันชักจะเริ่มเขียน test ยาก ทำให้เราต้องกลับมาดู design ของเราว่ามันมีอะไรผิดไป และเราควรจะเริ่มแตกปัญหาออกมาเป็น class เล็กๆ เพื่อให้สามารถเขียน unit test ได้ง่ายๆ ซึ่ง God class ที่ผมเจอมาคือมักจะไม่มี unit test มันจึงเป็นเรื่องที่ต้องออกแรงเยอะมากถ้าเราจะแก้มัน

อันดับแรก ต้องเริ่มที่ understanding เสมอ

ก็คือทำความเข้าใจของที่อยู่ข้างในนั้นก่อน ซึ่งแน่นอนว่าไม่ง่าย สิ่งที่ผมทำก็คือ ถามว่า ไอ้นี่มันทดสอบยังไง ทั้งแบบ manual และเอามาเขียนเป็น acceptance test กับ integration test ก่อน อาจจะดูง่ายๆ แต่ใช้เวลานานมากนะครับ มันคือการลองผิดลองถูก explore มันไปเรื่อยๆ crosss check กับหลายๆคนเลยว่ามันถูกมั้ย จะให้ดีก็เอา QA มา pair ด้วยเลย ซึ่งไม่ค่อยมีโอกาสเท่าไหร่หรอก

พอเข้าใจโค้ดระดับหนึ่งแล้ว ผมก็จะมองหาจุดที่จะ improve สำหรับ God class ก็คือเราจะแยกชิ้นส่วนมันออกมาเป็น class เล็กๆ ได้อย่างไร

เทคนิคที่ใช้ก็คือมองหา รอยต่อ(Seams) ภายใน class ยกตัวอย่างแบบง่ายๆเช่น กลุ่มของ method หรือ ตัวแปร ที่ไม่ได้มีความเกี่ยวของกัน อันนี้สามารถจับแยกเป็นคนละ class ได้เลย แต่ก็ไม่ได้ง่ายแบบนั้นเสมอไป ตรงนี้ต้องใช้ความชำนาญสักหน่อยครับ และต้องใช้ design principle หรือ pattern ต่างๆเข้ามาแก้ปัญหา

พอหารอยต่อได้แล้ว ก็จะเอามา design แล้วลงมือเขียน unit test แล้วค่อยๆ refactor ตามขั้นตอนนี้ไปเรื่อยๆ

แล้วจะต้อง refactor ไปถึงไหน? อันนี้ก็แล้วแต่ตกลงกัน ยกตัวอย่างเช่น

Test coverage ถึงค่าที่กำหนด เช่น 90% (Code เกือบทั้งหมด มี unit test)
ให้ทีมทำ code review แล้วไม่พบ issue ที่ยอมรับไม่ได้

การ Refactor แบบล้มยักษ์แบบนี้ไม่ควรเกิดขึ้นบ่อยๆ หรือไม่ควรเกิดเลย เพราะมันสิ้นเปลืองเพราะเราก็ต้องใช้เวลาของ developer ในการทำ แล้วในมุมของ business มันก็ถือว่าไม่เกิด progress ใดๆ แทนที่จะได้เอาเวลาไปทำ feature ใหม่ๆ กลับต้องเอาเวลามาใช้หนี้ทางเทคนิคเหล่านี้ แต่มันก็เป็นสิ่งที่ละเลยไม่ได้ถ้าจะทำงานกันไปยาวๆ แต่จากประสบการณ์ของผม ยิ่งโปรเจคเร่งรัดมากเท่าไหร่ ก็มีโอกาสเจอมากเท่านั้นแหละ

ดังนั้น ป้องกันไม่ให้มันเกิดจะดีที่สุดนะครับ

เพิ่มเติม
Code smells (Code ที่ไม่ดีเป็นอย่างไร)
https://refactoring.guru/refactoring/smells

Refactoring recipes (วิธีการ Refactor แบบต่างๆ)
https://refactoring.guru/refactoring/techniques

Seams (การหารอยต่อใน code)
https://www.informit.com/articles/article.aspx?p=359417&seqNum=2

บันทึก การ Redirect ของ LIFF App

Prayoch Rujira — Fri, 21 Jan 2022 05:31:14 +0000

ช่วงนี้วุ่นๆกับการทำ LIFF แล้วติดปัญหาเวลามี parameter แล้วงงกับพฤติกรรมของมันเวลา Redirect
ทาง Line เค้าก็ทำ Video กับ Document อธิบายไว้แล้วแหละ แต่ก็ยังไม่ค่อยเข้าใจอยู่ดี เลยต้องลองด้วยตัวเอง

โจทย์ก็คือ เรามี LIFF Url แบบนี้

https://liff.line.me/1656449211-9Kym0GQ7

เวลาใช้จริงเราก็อยากจะแนบ query parameter เข้าไปด้วย แบบนี้

https://liff.line.me/1656449211-9Kym0GQ7?template_id=1

เมื่อเราเปิด LIFF จากใน line จะเจอว่า มีการเรียกมาที่ /?liff.state=%3Ftemplate_id%3D1

เมื่อทำการ initialize สำเร็จ จะมีการเรียกเข้ามาอีกครั้งที่ /?template_id=1 และ สามารถอ่านค่า query param ได้

สรุปว่า query param ไม่ได้หายไปไหน แต่ต้องอ่านให้ถูก ถ้าจะอ่านจาก redirect ครั้งแรก มันจะถูก encode มาใน liff.state
แต่ถ้าจะอ่านจาก redirect ครั้งที่สอง ก็อ่านจาก URL ตามปกติ