17｜如何与LLM结对编程

我一直有一个疑问，到底是任务列表？还是测试列表？ 还是先根据软件架构和测试策略将需求切到足够小，形成任务列表，在针对任务列表中的每个任务写出测试，从而形成测试列表。 之前提到过用户故事及验收条件，用户故事需要根据软件架构和测试策略再切分吗？验收条件，是不是就是测试列表或者测试列表的一部分？ 后面会有复杂点的例子，介绍需求如何从用户故事，到被不同软件架构，测试策略组合影响，从而导出不同的任务列表，进而导出测试列列表的过程吗？

我认为应该是庞杂+清晰 庞杂的认知行为模式，从gpt给与的需求拆分的任务列表，我们和llm进行认知对齐，帮其弥补llm认知需求的差异，在该模式下我们根据对齐的任务列表生成测试代码和生产代码 清晰的认知行为模式，根据测试代码执行进行测试来发现生产代码上的遗漏，发现错误,与llm进行交互调整生产代码，最终完成测试的通过。 这里有两个疑问 1. 假设根据测试代码执行发现未知的错误(此时无法与gpt进行交互)，我们也不理解改错误的信息，我们此时就需要debug一步步调试，此时我们本身又处于复杂模式下(探索-感知-响应)，而可以和llm交互后我们又处于清晰模式下(感知-分类-响应)。我们因为一个llm帮助我们的认知行为发生了两个重大的变更吗？ 2. TDD测试驱动,红-绿-重构，这节课里没看到重构循环,感觉缺少了点啥

学习后收获了 2 个模版 练习后获得经验：需要认真检查 AI 列出的测试场景，不然会出现奇怪的代码！ 实用的 AI 模版 ====== 列出测试场景 ---------------- 功能需求 ==== {requirement} 任务 ==== 请根据上面的功能需求，列出需要测试的场景。描述场景，并给出相关的测试数据。 编写测试代码 ---------------- 请生成 junit junpiter 测试 要求： 每个场景对应一个测试方法 使用 Kotlin 编写 使用 TDD 中的 should style 编写测试 详见 https://wyyl1.com/post/28/17

// Question by EnigmaWU: generate could missing ut code for me // Answer from ChatCopilot: TEST(CC_parseCmdLineArgs, LogSavingDir) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-d", (char *)"/path/to/log"}; EXPECT_EQ(CC_SUCCESS, CC_parseCmdLineArgs(3, argv, &CmdLineArgs)); EXPECT_FALSE(CmdLineArgs.IsLoggingEnabled); EXPECT_EQ(0, CmdLineArgs.RecvPort); EXPECT_STREQ("/path/to/log", CmdLineArgs.pLogSavingDir); } TEST(CC_parseCmdLineArgs, InvalidArgs) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"invalid"}; EXPECT_EQ(CC_FAIL, CC_parseCmdLineArgs(2, argv, &CmdLineArgs)); } TEST(CC_parseCmdLineArgs, MissingValueForPort) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-p"}; EXPECT_EQ(CC_FAIL, CC_parseCmdLineArgs(2, argv, &CmdLineArgs)); } TEST(CC_parseCmdLineArgs, MissingValueForDir) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-d"}; EXPECT_EQ(CC_FAIL, CC_parseCmdLineArgs(2, argv, &CmdLineArgs)); } TEST(CC_parseCmdLineArgs, NonNumericPort) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-p", (char *)"nonnumeric"}; EXPECT_EQ(CC_FAIL, CC_parseCmdLineArgs(3, argv, &CmdLineArgs)); } TEST(CC_parseCmdLineArgs, MultipleSameArgs) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-l", (char *)"-l"}; EXPECT_EQ(CC_SUCCESS, CC_parseCmdLineArgs(3, argv, &CmdLineArgs)); EXPECT_TRUE(CmdLineArgs.IsLoggingEnabled); } TEST(CC_parseCmdLineArgs, ArgsInDifferentOrder) { CC_CmdLineArgs_T CmdLineArgs; char *argv[] = {(char *)"test", (char *)"-p", (char *)"1234", (char *)"-l", (char *)"-d", (char *)"/path/to/log"}; EXPECT_EQ(CC_SUCCESS, CC_parseCmdLineArgs(6, argv, &CmdLineArgs)); EXPECT_TRUE(CmdLineArgs.IsLoggingEnabled); EXPECT_EQ(1234, CmdLineArgs.RecvPort); EXPECT_STREQ("/path/to/log", CmdLineArgs.pLogSavingDir); }

// Chat with Copilot, Question by EnigmaWU: // #file:CC_parseCmdLineArgs.c #file:CC_parseCmdLineArgsTest_byCopilot.cxx // what UT already written and what UT is missed? ////////////////////////////////////////////////////////////////////////////// // Answer from ChatCopilot: /** The unit tests that are already written for the CC_parseCmdLineArgs function in the CC_parseCmdLineArgsTest_byCopilot.cxx file are: NullCmdLineArgs: Tests the function with argc as 0 and argv as NULL. NullCmdLineArgsPtr: Tests the function with argc as 0, argv as NULL, and pCmdLineArgs as NULL. NoArgs: Tests the function with no command line arguments. LoggingEnabled: Tests the function with the logging enabled argument -l. RecvPort: Tests the function with the receive port argument -p and a value. LogSavingDir: Tests the function with the log saving directory argument -d and a value. AllArgs: Tests the function with all possible arguments. The unit tests that are missing could be: InvalidArgs: Tests the function with invalid arguments that do not start with -. MissingValueForPort: Tests the function with the -p argument but without a value following it. MissingValueForDir: Tests the function with the -d argument but without a value following it. NonNumericPort: Tests the function with a non-numeric value for the -p argument. MultipleSameArgs: Tests the function with multiple instances of the same argument. ArgsInDifferentOrder: Tests the function with all possible arguments in a different order. **/