iT邦幫忙

2025 iThome 鐵人賽

DAY 6
0
生成式 AI

30 天與 AI 同事打造系統的求生實錄系列 第 6

【Day 6】debug地獄到曙光:我和 AI 合作修測試的故事

  • 分享至 

  • xImage
  •  

今天是鐵人賽第六天,昨天搞定了建置pytest環境後,今天開始對pytest去DEBUG
不過由於剛好看到如何解決gemini cli帳號登入時出現的
Failed to login. Message: Precondition check failed.
我就趁這機會先解決了~

解決完之後,為了使用 MCP 的 context7,去設定 Gemini 的 MCP 設定檔,使 AI 同事能使用 context7 查套件的文件資料。

之後就是debug地獄了,先解決了資料庫帳密錯誤,這主要是前期建立後有改過帳密但是資料庫沒有清空更新,導致由於是舊的密碼無法連線。
pytest的測試非同步功能出現很多問題,光憑AI同事gemini無法解決,我又請除錯小幫手ChatGPT幫忙,但還是卡了很久沒有解決。
後來發現是gemini的文本太長影響gemini的判斷,因此使用/clear指令去清除所有文本後,重新使用了解應用現況的指令後,重新開始修復BUG,這次就有比較順利的感覺,而不是像剛才一直來回用一樣的方法去修

不過用這些方法還是很難讓同事解決這些錯誤,因此這裡我決定人工介入,不把全部錯誤訊息丟給AI同事,而是只抓關鍵錯誤訊息給AI去解析,這才讓AI同事給我正確的解決方法,我再手動去處理那些錯誤的地方,最終終於把測試全部pass。

在debug時常常挖東牆補西牆,沒介入篩選資訊確實輕鬆,但AI同事對處理未篩選的錯誤訊息還是太容易被誤導,以我目前選擇的模型能力,還是需要一定的人工介入篩選要給AI的資訊,才容易解決問題。
不然看AI同事在那邊繞圈圈,其實很燒耐心XD

以下為今天的研究流程


在開始之前,我先來解決前陣子gemini cli登入帳號的問題
之前在某次更新後,你如果使用google帳號登入會出現

Failed to login. Message: Precondition check failed.

我原本因為這個問題改用google api key的方式登入
今天剛好看到有人分享解法,我嘗試了一下就順利解決了

這個問題的原因是 gemini cli在修正bug後,假如你的環境變數有 GOOGLE_CLOUD_PROJECT,他會去比對導致驗證失敗。
我作業系統是用windows 10,因此我直接去環境變數的地方將 GOOGLE_CLOUD_PROJECT變數刪除,果然就能正常使用google帳號驗證了


首先開啟前的老樣子,請AI同事了解應用現況。
我給AI的指令:

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

等AI同事了解現況之後,我執行了昨天AI同是讓我執行的指令

pytest tests

結果出現了大量錯誤,不過這也很正常,有使用AI建構程式的經驗應該都知道,很多時候AI同事都沒辦法一步到位
錯誤訊息有點多,我列出幾個

ERROR tests/test_users.py::test_create_user - sqlalchemy.exc.MissingGreenlet: greenlet_spawn has not been called; can't call await_only() here. Was IO attempted ...
ERROR tests/test_users.py::test_create_user_existing_username - sqlalchemy.exc.MissingGreenlet: greenlet_spawn has not been called; can't call await_only() here. Was IO attempted ...
...

看起來大部分都是類似的錯誤,can't call await_only(),我請AI同事分析這個錯誤,這時有個小技巧
如果你直接複製錯誤碼去貼在gemini cli上,因為有換行符號的關係,他會在換行的時後直接執行,沒辦法貼上完整的錯誤碼
這時我會透過先貼在其他地方,例如瀏覽器網址列(或者你順手的地方),貼上後再複製下來,因為這種地方會自動幫你把換行符號處理掉,就可以順利將完整錯誤訊息貼給AI同事了
AI同事分析,應該是測試資料跟程式環境不同,一個使用同步一個使用非同步環境,導致資料庫操作的程式沒有正常執行,因此將環境修正成非同步。
在處理過程中,誤用了AsyncSession的用法,這次AI同事比較聰明,他自己上網搜了用法去修正,成功修正了錯誤。
處理完之後,又跳出了資料庫密碼錯誤,比對後發現帳密一致,猜測可能是之前建立後修改過帳密導致可能用到舊的
因此刪除資料庫快取重新又建構了一次資料庫容器,但還是無效。
這時為了避免AI同事鑽牛角尖,我中斷了他的嘗試,先請他檢查資料庫的帳號密碼設定是否有問題,但失敗了
為了排除問題,我先用資料庫連線軟體手動測試一次(這裡我使用DBeaver),但果然還是跳出密碼驗證失敗

最後我測試了手動連線docker容器去修改密碼後,解決的這個問題。
會出現這個問題是因為我在之前還在調整docker-compose.yml時建立過一次容器,由於我使用volumes去保留我的資料庫資料,導致他的帳密還是第一次創建時的帳密,因此除了進入容器修改外,還可以透過docker指令刪除去刪除舊的資料讓他重新建立一個全新的資料庫。

解決掉自己埋的資料庫容器BUG後,終於可以繼續推進pytest,還好AI同事不會抱怨XD
不過這次出現了一直出現同樣錯誤無法解決。
因此我想請AI同事帶入後端工程師的角度去檢查
我給AI的指令:

請用 @agents/engineering/backend-architect.md 重新檢查錯誤 

AI同事開始會擴大眼界去分析錯誤,跳過了錯誤循環。
他提出了錯誤修改計畫,我通常會補上一個指令。

好的,並檢查其他類似的地方是否也有需要修改的地方

因為他在修復錯誤時,有時候只專注在出錯的那個範圍,但有些時候,很多地方會有類似的問題,又或者他是需要改三個地方,但他只改了其中一個地方
我會讓AI同事去意識,要去檢查其他地方,才不會來來回回一直修改同樣的錯誤。

在這個階段,AI同事一直卡在AsyncClient與TestClient與在pytest-asyncio環境下遇到事件循環問題
我為了繞開這個問題,我問了我的DEBUG小幫手ChatGPT,他建議我改用httpx.AsyncClient可以避開衝突問題
於是我請AI同事測試一下小幫手提議的方法
我給AI的指令:

之前的方法都會有衝突問題,請幫我把那些地方都改成用 httpx.AsyncClient 測試

結果出現新的問題

 TypeError: __init__() got an unexpected keyword argument 'app'

問了一下DEBUG小幫手,有可能是版本問題,但查了一下httpx版本是新的,這時我決定與其這樣猜,我直接使用Context7的mcp去幫我查詢httpx這個文件
要使用這個mcp只要你在你的資料夾中創建一個 .gemini 的資料夾,並在裡面建立settings.json
放入以下內容

{
  "contextFileName": "GEMINI.md","contextFileName": "GEMINI.md",
  "mcpServers": {
    "Context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

重新啟動gemini他就會在啟動時安裝mcp讓你可以呼叫。

之後我給AI同事下了請他查詢文件的指令。
我給AI的指令:

使用Context7去檢查httpx用法

他查完給出的回答是

我已經獲取了 httpx 的文件。從文件中可以看出,httpx.AsyncClient 的 init 方法確實沒有 app 參數。
httpx.AsyncClient 的初始化方式是 httpx.AsyncClient(transport=transport,base_url="http://testserver"),其中 transport 參數可以是一個 httpx.ASGITransport 實例,而 ASGITransport則接受 app 參數。
這就是我們之前遇到的 TypeError: init() got an unexpected keyword argument 'app' 的原因。

接下來出現下一個問題

AttributeError: 'AsyncSession' object has no attribute 'exec'

不過由於我前面有使用context7,他這次比較聰明的先去查文件,但查文件並更新套件版本後還是沒有解決
我只好又再次去詢問小幫手,他給出的建議如下

建議這樣導入 SQLModel 的 AsyncSession:
from sqlmodel.ext.asyncio.session import AsyncSession

今天倒在了處理非同步測試問題,我透過gemini與ChatGPT合作,來回協調但沒有處理成功
後來我發現,由於我處理錯誤產生太多文本,導致gemini本身受到那些錯誤方法與文本影響,功能下降很多
我利用/clear指令清空所有文本,讓他再跑一次了解應用的指令,他處理錯誤就比較正常了
不會一直循環使用失敗的方法來回處理。

但最後,整個錯誤訊息丟給AI同事去處理還是失敗了,太多雜訊導致AI同事一直給出錯誤解答,我只好手動篩選關鍵錯誤訊息餵給ChatGPT,然後手動用GPT給我的解法去處理,終於解決了測試問題,全部pass。


上一篇
【Day 5】AI同事是幫手不是主導,錯誤別跟著它硬上!
下一篇
【Day 7】技術可以靠 AI,判斷得靠自己:一週實戰後的合作策略盤點
系列文
30 天與 AI 同事打造系統的求生實錄30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言