mirror of
https://github.com/vczh-libraries/Release.git
synced 2026-02-05 11:30:07 +08:00
...
This commit is contained in:
vczh
19
.github/copilot-instructions.md
vendored
19
.github/copilot-instructions.md
vendored
@@ -19,6 +19,7 @@ This project is built on top of:
|
||||
- Find out the `Accessing the Knowledge Base` section, read `Index.md` of `KnowledgeBase` project in the current solution.
|
||||
- Before generating any code, if the file is changed, read it. Not all changes come from you, I will edit the file too. Do not generate code based on out-dated version in your memory.
|
||||
- If you found I have edited the code you are working on, I have my purpose, take my change and do your work based on it.
|
||||
- If a `*.prompt.md` file is referenced at the beginning of the LATEST chat message, I would like you to take action following instruction in that file.
|
||||
|
||||
## Solution and Project File Structure
|
||||
|
||||
@@ -135,6 +136,7 @@ TEST_FILE
|
||||
|
||||
Please refer to the `Accessing the Knowledge Base` section for more information about advanced features in unit test.
|
||||
IMPORTANT: Unlike `TEST_FILE` which ends with `}`, `TEST_CASE` and `TEST_CATEGORY` ends with `});`.
|
||||
|
||||
# Writing GacUI Unit Test
|
||||
|
||||
Here are some basic rules.
|
||||
@@ -196,14 +198,25 @@ If multiple test cases are in the same file:
|
||||
- There can be multiple `TEST_CASE` in a `TEST_CATEGORY`.
|
||||
- There name will also appear in the arguments to `GacUIUnitTest_StartFast_WithResourceAsText` unless directed.
|
||||
|
||||
In `GacUIUnitTest_SetGuiMainProxy`, there will be multiple `protocol->OnNextIdleFrame`. Each creates a new frame.
|
||||
Name of the frame does not say what to do in this frame, but actually what have been done previously.
|
||||
The code of the last frame is always closing the window.
|
||||
In `GacUIUnitTest_SetGuiMainProxy`, there will be multiple `protocol->OnNextIdleFrame`.
|
||||
Each call creates a frame, associating the name to the what the UI was before frame execution.
|
||||
|
||||
If there are shared variable that updates in any frame in one `TEST_CASE`, they must be organized like this:
|
||||
- Shared variables should be only in `TEST_CASE`.
|
||||
- Lambda captures should be exactly like this example, `[&]` for the proxy and `[&, protocol]` for the frame.
|
||||
|
||||
## Organizing Frames
|
||||
|
||||
After an UI test case is executed, the whole UI will be captured and logged to files per frames.
|
||||
Each frame shows how the UI was before executing code inside a frame.
|
||||
In order to make these log human-familiar, please follow these rules:
|
||||
- Always name the first frame "Ready".
|
||||
- Name other frames for what the previous frame does. This is demoed in the example, as "Clicked this button" is the name of the second frame, while clicking the button happens in the first frame.
|
||||
- Action and verification are better to be in the same frame.
|
||||
- A frame should introduce UI changing. Otherwise the unit test will crash with a specific error.
|
||||
- Keep the last frame only calling `window->Hide();` if possible. But if no meaningful UI change is introduced in the previous frame, it is OK to merge them.
|
||||
- Do not introduce unnecessary UI change just to separate frames. UI change must be necessary and meaningful for the test case.
|
||||
|
||||
```C++
|
||||
TEST_CASE(L"Topic")
|
||||
{
|
||||
|
||||
117
.github/prompts/win-0-scrum.prompt.md
vendored
117
.github/prompts/win-0-scrum.prompt.md
vendored
@@ -8,6 +8,8 @@
|
||||
- Your goal is to finish a design document in `Copilot_Scrum.md` to address a problem.
|
||||
- You are only allowed to update `Copilot_Scrum.md`.
|
||||
- You are not allowed to modify any other files.
|
||||
- The phrasing of the request may look like asking for code change, but your actual work is to write the design document.
|
||||
- "Task" in the request always mean a task under the `# TASKS` section in the design document.
|
||||
|
||||
## Copilot_Scrum.md Structure
|
||||
|
||||
@@ -20,7 +22,6 @@
|
||||
- `## TASK No.X: The Task Title`: A task.
|
||||
- A comprehensive description about the goal of this task.
|
||||
- `### what to be done`: A clear definition of what needs to be changed or implemented.
|
||||
- `### how to test it`: A clear definition of what needs to be tested in unit test.
|
||||
- `### rationale`: Reasons about why you think it is necessary to have this task, why you think it is the best for the task to be in this order.
|
||||
- `# Impact to the Knowledge Base`:
|
||||
- `## ProjectName`: What needs to be changed or added to the knowledge base in this project.
|
||||
@@ -28,28 +29,56 @@
|
||||
## Step 1. Identify the Problem
|
||||
|
||||
- The problem I would like to solve is in the chat messages sending with this request.
|
||||
- Find `# Problem` or `# Update` or `# Learn` in the LATEST chat message. Ignore any `# Problem` or `# Update` in the chat history.
|
||||
- If there is a `# Problem` section: it means I am starting a fresh new request.
|
||||
- You should override `Copilot_Scrum.md` with only one title `# !!!SCRUM!!!`.
|
||||
- At the moment, `Copilot_Scrum.md` may contain old tasks from previous requests, even it may look like the document is already finished for the current scrum, always clean it up.
|
||||
- After overriding, copy precisely my problem description in `# Problem` from the LATEST chat message under `# DESIGN REQUEST`.
|
||||
- Add an empty `# UPDATES` section after `# DESIGN REQUEST`.
|
||||
- If there is an `# Update` section: it means I am going to propose some change to `Copilot_Scrum.md`.
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# DESIGN REQUEST` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# TASKS`).
|
||||
- When the number of tasks needs to be changed, due to inserting/removing/splitting/merging tasks:
|
||||
- Adjust task number of unaffected tasks accordingly, throughout the document.
|
||||
- Replace the affected tasks with new content, DO NOT TOUCH unaffected tasks.
|
||||
- Follow my update to change the design document.
|
||||
- If there is a `# Learn` section: it means I made important updates during the execution of the last task, you should apply them smart enough to future tasks. Find the `Optional Step for Learning` section for more instruction.
|
||||
- If there is nothing: it means you are accidentally stopped. Please continue your work.
|
||||
- Find `# Problem` or `# Update` or `# Learn` in the LATEST chat message.
|
||||
- Ignore any these titles in the chat history.
|
||||
- If there is nothing: it means you are accidentally stopped. Please continue your work.
|
||||
|
||||
### Create new Document (only when "# Problem" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Problem" in the LATEST chat message
|
||||
I am starting a fresh new request.
|
||||
|
||||
- You should override `Copilot_Scrum.md` with only one title `# !!!SCRUM!!!`.
|
||||
- At the moment, `Copilot_Scrum.md` may contain old tasks from previous requests, even it may look like the document is already finished for the current scrum, always clean it up.
|
||||
- After overriding, copy precisely my problem description in `# Problem` from the LATEST chat message under `# DESIGN REQUEST`.
|
||||
- Add an empty `# UPDATES` section after `# DESIGN REQUEST`.
|
||||
|
||||
### Update current Document (only when "# Update" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Update" in the LATEST chat message
|
||||
I am going to propose some change to `Copilot_Scrum.md`.
|
||||
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# DESIGN REQUEST` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# TASKS`).
|
||||
- When the number of tasks needs to be changed, due to inserting/removing/splitting/merging tasks:
|
||||
- Adjust task number of unaffected tasks accordingly, throughout the document.
|
||||
- Replace the affected tasks with new content, DO NOT TOUCH unaffected tasks.
|
||||
- Follow my update to change the design document.
|
||||
|
||||
### Learning (only when "# Learn" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Learn" in the LATEST chat message
|
||||
I made important updates to the source code manually during the execution of the last task.
|
||||
|
||||
- Skip every steps before Step 6.
|
||||
- Find the `Step 6. Learning` section for more instruction.
|
||||
|
||||
## Step 2. Understand the Goal and Quality Requirement
|
||||
|
||||
- Your goal is to help me break down the problem into small tasks, write it down to `Copilot_Scrum.md`.
|
||||
- Each task should be small enough to only represent a single idea or feature upgrade.
|
||||
- Each task should be big enough to deliver a complete piece of functionality, do not make a task that only add code that will not be executed.
|
||||
- The order of tasks is important. At the end of each task, the project should be able to compile and test.
|
||||
- Each task should be:
|
||||
- Small enough to only represent a single idea or feature upgrade.
|
||||
- Deliver a complete piece of functionality.
|
||||
- Not mixing functionality and test cases in the same task.
|
||||
- In case when new unit test is required, writing new test cases should be in separate tasks.
|
||||
- If test cases are better to be categorized and grouped with multiple `TEST_CATEGORY`, create each task for each `TEST_CATEGORY`.
|
||||
- For refactoring work, existing test cases might have already covered most of the scenarios. Carefully review them and only add new test cases if necessary.
|
||||
- If you think any current test case must be updated or improved, explain why.
|
||||
- For a test planning task:
|
||||
- The test plan is about writing unit test cases. Do not include end-to-end tests or manual tests.
|
||||
- Sometimes it is difficult to make relevant unit test, for example a change to the UI, you can skip the test plan but you need to provide a rationale for it.
|
||||
- You do not need to design test cases or think about code coverage at this moment. Instead consider about how to ensure testability, how many existing components are affected so that they need to be tested, and figure out if existing test cases already covered affected components or not.
|
||||
- Well ordered. At the end of each task, the project should be able to compile or test.
|
||||
- During making the design document:
|
||||
- Take in consideration of the knowledge base, finding anything that would be helpful for the current problem.
|
||||
- Read through the code base carefully. The project is complicated, one small decision may have widely impact to the other part of the project.
|
||||
@@ -57,21 +86,30 @@
|
||||
|
||||
## Step 3. Finish the Document
|
||||
|
||||
- Break the problem in to tasks.
|
||||
- Break the problem into tasks.
|
||||
- In each task, describe a task in a high level and comprehensive description.
|
||||
- A task must be at least updating some code, it must not be like learning or analysing or whatever just reading. Reading, thinking and planning is your immediate work to do.
|
||||
- A task must be at least updating some code, it must not be like learning or analysing or whatever just reading.
|
||||
- Reading, thinking and planning is your immediate work to do to complete the design document.
|
||||
- Following the description, there should also be:
|
||||
- `### what to be done`: A clear definition of what needs to be changed or implemented.
|
||||
- Keep it high-level, you can mention what should be done to update a certain group of classes, but do not include any actual code change.
|
||||
- `### how to test it`: A clear definition of what needs to be tested in unit test.
|
||||
- The test plan is about writing unit test cases. Do not include end-to-end tests or manual tests.
|
||||
- Sometimes it is difficult to make relevant unit test, for example a change to the UI, you can skip the test plan but you need to provide a rationale for it.
|
||||
- You do not need to design test cases or think about code coverage at this moment. Instead consider about how to ensure testability, how many existing components are affected so that they need to be tested, and figure out if existing test cases already covered affected components or not.
|
||||
- `### rationale`:
|
||||
- Reasons about why you think it is necessary to have this task, why you think it is the best for the task to be in this order.
|
||||
- Any support evidences from source code or knowledge base.
|
||||
- If you can't find anything from the knowledge base, think about what can be added to the knowledge base, but you do not need to actually update the knowledge base at the moment.
|
||||
|
||||
### Tips about Designing
|
||||
|
||||
- Leverage the source code from dependencies in `Import` folder as much as you can.
|
||||
- Source code in the `Source` and `Test` folder is subject to modify.
|
||||
- The project should be highly organized in a modular way. In most of the cases you are using existing code as API to complete a new feature.
|
||||
- If you think any existing API in the current project should offer enough functionality, but it is currently missing something:
|
||||
- Point it out. A separate task to update them is recommended.
|
||||
- DO NOT make assumption that you can't prove.
|
||||
- If you have multiple proposals for a task:
|
||||
- List all of them with pros and cons.
|
||||
- You should decide which is the best one.
|
||||
|
||||
## Step 4. Identify Changes to Knowledge Base
|
||||
|
||||
- It is important to keep the knowledge base up to date.
|
||||
@@ -88,9 +126,9 @@
|
||||
|
||||
- Ensure there is a `# !!!FINISHED!!!` mark at the end of `Copilot_Scrum.md` to indicate the document reaches the end.
|
||||
|
||||
## (Optional) Step 6. Learning (only when # Learn appears in the LATEST chat message)
|
||||
## Step 6. Learning (only when "# Learn" appears in the LATEST chat message)
|
||||
|
||||
- Ignore this section if there is no `# Learn` in the LATEST chat message
|
||||
- Ignore this section if there is no "# Learn" in the LATEST chat message
|
||||
|
||||
### Step 6.1. Identify the Last Complteted Task
|
||||
|
||||
@@ -111,10 +149,15 @@
|
||||
- Any other difference is a user edit.
|
||||
- If there is no `# !!!VERIFIED!!!` in `Copilot_Execution.md`, it means you failed to deliver the task, either the code did not compile or some test cases failed. My edit will also reflects the final solution to the task.
|
||||
- Carefully read through and analyse all user edits, understand my tastes and preferences about the source code.
|
||||
- Add your finding to `Copilot_Execution.md` at the very end with the topic `# Comparing to User Edit`.
|
||||
- If every changes are ignored by the rule above, or if you can't find any user edit, just write `No user edit found`.
|
||||
|
||||
### Step 6.3 Learn
|
||||
### Step 6.3 Write Down Findings
|
||||
|
||||
- If every changes are ignored by the rule above, skip thi step.
|
||||
- Create a new file `Copilot_Execution_Finding.md` with a topic `# Comparing to User Edit`.
|
||||
- `Copilot_Execution_Finding.md` should stay in the same folder as `Copilot_Execution.md`.
|
||||
- Add your finding to `Copilot_Execution_Finding.md`.
|
||||
|
||||
### Step 6.4 Learn
|
||||
|
||||
- There will be multiple `# UPDATES` or `# FIXING ATTEMPTS` or `# Comparing to User Edit` sections in `Copilot_Task.md`, `Copilot_Planning.md` and `Copilot_Execution.md`.
|
||||
- These 3 files recorded how you interpreted the last completed task, and how I wanted you to adjust your understanding.
|
||||
@@ -122,12 +165,20 @@
|
||||
- Check all future tasks, apply what you have learned, and adjust your approach accordingly.
|
||||
- For each unfinished tasks that can be improved, update releated learnings in `Copilot_Scrum.md`.
|
||||
|
||||
### Step 6.4 Backup
|
||||
### Step 6.5 Backup
|
||||
|
||||
- You must only run this step after finishing all above steps.
|
||||
- In the above steps, necessary change will be updated to `Copilot_Execution.md` and `Copilot_Scrum.md`.
|
||||
- Find and execute `copilotPrepare.ps1 -Backup`. You MUST use the `-Backup` parameter.
|
||||
- Remember the first line of the output, it has the absolute path to the backup folder.
|
||||
- By running the backup script, `Copilot_Task.md`, `Copilot_Planning.md` and `Copilot_Execution.md` will be backed up and deleted.
|
||||
- If you created `Copilot_Execution_Finding.md`, in Step 6.3:
|
||||
- In the backup folder, there will be a copied `Copilot_Execution.md`, append all contents from `Copilot_Execution_Finding.md` to the end of it.
|
||||
- Delete the `Copilot_Execution_Finding.md` you created.
|
||||
- Run `git status` to make sure you have manipulate document files correctly:
|
||||
- `Copilot_Scrum.md` is modified, unless nothing needs to be changed.
|
||||
- `Copilot_Task.md`, `Copilot_Planning.md` and `Copilot_Execution.md` are created in a backup folder.
|
||||
- There is no `Copilot_Execution_Finding.md`.
|
||||
|
||||
# External Tools Environment and Context
|
||||
|
||||
@@ -153,9 +204,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
|
||||
68
.github/prompts/win-1-design.prompt.md
vendored
68
.github/prompts/win-1-design.prompt.md
vendored
@@ -8,8 +8,7 @@
|
||||
- Your goal is to finish a design document in `Copilot_Task.md` to address a problem.
|
||||
- You are only allowed to update `Copilot_Task.md` and mark a task completed in `Copilot_Scrum.md`.
|
||||
- You are not allowed to modify any other files.
|
||||
- Anything in the instruction is a guidance to complete `Copilot_Task.md`.
|
||||
- DO NOT modify any source code.
|
||||
- The phrasing of the request may look like asking for code change, but your actual work is to write the design document.
|
||||
|
||||
## Copilot_Task.md Structure
|
||||
|
||||
@@ -22,23 +21,34 @@
|
||||
## Step 1. Identify the Problem
|
||||
|
||||
- The problem I would like to solve is in the chat messages sending with this request.
|
||||
- Find `# Problem` or `# Update` in the LATEST chat message. Ignore any `# Problem` or `# Update` in the chat history.
|
||||
- If there is a `# Problem` section: it means you are on a fresh start.
|
||||
- Find and execute `copilotPrepare.ps1` to clean up everything from the last run.
|
||||
- After `copilotPrepare.ps1` finishes, copy precisely my problem description in `# Problem` from the LATEST chat message under a `# PROBLEM DESCRIPTION`.
|
||||
- If the problem description is `Next`:
|
||||
- Find the first incomplete task in `Copilot_Scrum.md`, and follow the intruction below to process that task.
|
||||
- If the problem description is like `Complete task No.X`:
|
||||
- Locate the specific task in `Copilot_Scrum.md`.
|
||||
- There is a bullet list of all tasks at the beginning of `# TASKS`. Mark the specific task as being processed by changing `[ ]` to `[x]`.
|
||||
- Find the details of the specific task, copy everything in this task to `# PROBLEM DESCRIPTION`.
|
||||
- Add an empty `# UPDATES` section after `# PROBLEM DESCRIPTION`.
|
||||
- If there is an `# Update` section: it means I am going to propose some change to `Copilot_Task.md`.
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# PROBLEM DESCRIPTION` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# INSIGHTS AND REASONING`).
|
||||
- Follow my update to change the design document.
|
||||
- If there is nothing: it means you are accidentally stopped. Please continue your work.
|
||||
- Read `Copilot_Task.md` througly, it is highly possibly that you were working on the request described in the last section in `# PROBLEM DESCRIPTION`.
|
||||
- Find `# Problem` or `# Update` in the LATEST chat message.
|
||||
- Ignore any these titles in the chat history.
|
||||
- If there is nothing: it means you are accidentally stopped. Please continue your work.
|
||||
- Read `Copilot_Task.md` througly, it is highly possibly that you were working on the request described in the last section in `# PROBLEM DESCRIPTION`.
|
||||
|
||||
### Create new Document (only when "# Problem" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Problem" in the LATEST chat message
|
||||
I am starting a fresh new request.
|
||||
|
||||
- Find and execute `copilotPrepare.ps1` to clean up everything from the last run.
|
||||
- After `copilotPrepare.ps1` finishes, copy precisely my problem description in `# Problem` from the LATEST chat message under a `# PROBLEM DESCRIPTION`.
|
||||
- If the problem description is `Next`:
|
||||
- Find the first incomplete task in `Copilot_Scrum.md`, and follow the intruction below to process that task.
|
||||
- If the problem description is like `Complete task No.X`:
|
||||
- Locate the specific task in `Copilot_Scrum.md`.
|
||||
- There is a bullet list of all tasks at the beginning of `# TASKS`. Mark the specific task as being processed by changing `[ ]` to `[x]`.
|
||||
- Find the details of the specific task, copy everything in this task to `# PROBLEM DESCRIPTION`.
|
||||
- Add an empty `# UPDATES` section after `# PROBLEM DESCRIPTION`.
|
||||
|
||||
### Update current Document (only when "# Update" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Update" in the LATEST chat message
|
||||
I am going to propose some change to `Copilot_Task.md`.
|
||||
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# PROBLEM DESCRIPTION` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# INSIGHTS AND REASONING`).
|
||||
- Follow my update to change the design document.
|
||||
|
||||
## Step 2. Understand the Goal and Quality Requirement
|
||||
|
||||
@@ -47,7 +57,21 @@
|
||||
- The design document must describe the what to change, keep the description in high-level without digging into details about how to update the source code.
|
||||
- The design document must explain the reason behind the proposed changes.
|
||||
- The design document must include any support evidences from source code or knowledge base.
|
||||
- It is completely OK and even encouraged to have multiple solutions. You must explain each solution in a way mentioned above, and provide a comparison of their pros and cons.
|
||||
|
||||
### Tips about Designing
|
||||
|
||||
- Leverage the source code from dependencies in `Import` folder as much as you can.
|
||||
- Source code in the `Source` and `Test` folder is subject to modify.
|
||||
- The project should be highly organized in a modular way. In most of the cases you are using existing code as API to complete a new feature.
|
||||
- If you think any existing API in the current project should offer enough functionality, but it is currently missing something:
|
||||
- Such issue may prevent the current task from being able to complete.
|
||||
- You should point it out.
|
||||
- I need such information to review incomplete tasks.
|
||||
- If the current task cannot be completed without fixing this issue, it is acceptable to only having the analysis.
|
||||
- DO NOT make assumption that you can't prove.
|
||||
- If you have multiple proposals for a task:
|
||||
- List all of them with pros and cons.
|
||||
- You should decide which is the best one.
|
||||
|
||||
## Step 3. Finish the Document
|
||||
|
||||
@@ -82,9 +106,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
|
||||
70
.github/prompts/win-2-planning.prompt.md
vendored
70
.github/prompts/win-2-planning.prompt.md
vendored
@@ -8,51 +8,63 @@
|
||||
- Your goal is to finish a planning document in `Copilot_Planning.md` to address a problem from `Copilot_Task.md`.
|
||||
- You are only allowed to update `Copilot_Planning.md`.
|
||||
- You are not allowed to modify any other files.
|
||||
- Anything in the instruction is a guidance to complete `Copilot_Planning.md`.
|
||||
- DO NOT modify any source code.
|
||||
- The phrasing of the request may look like asking for code change, but your actual work is to write the design document.
|
||||
|
||||
## Copilot_Planning.md Structure
|
||||
|
||||
- `# !!!PLANNING!!!`: This file always begin with this title.
|
||||
- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
|
||||
- `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
|
||||
- `# IMPROVEMENT PLAN`.
|
||||
- `# EXECUTION PLAN`.
|
||||
- `## STEP X: The Step Title`: One step in the improvement plan.
|
||||
- A clear description of what to change in the source code.
|
||||
- A clear explanation of why this change is necessary.
|
||||
- `# TEST PLAN`.
|
||||
|
||||
## Step 1. Identify the Problem
|
||||
|
||||
- The design document is in `Copilot_Task.md`. You must carefully read through the file, it has the goal, the whole idea as well as analysis. If `Copilot_Task.md` mentions anything about updating the knowledge base, ignore it.
|
||||
- Find `# Update` in the LATEST chat message. Ignore any `# Update` in the chat history.
|
||||
- If there is an `# Update` section: it means I am going to propose some change to `Copilot_Planning.md`.
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# IMPROVEMENT PLAN`).
|
||||
- Follow my update to change the planning document.
|
||||
- If there is nothing:
|
||||
- If `Copilot_Planning.md` only has a title, you are on a fresh start.
|
||||
- Add an empty `# UPDATES` section after the title, if it does not already exist.
|
||||
- Otherwise, it means you are accidentally stopped. Please continue your work.
|
||||
- Find `# Problem` or `# Update` in the LATEST chat message.
|
||||
- Ignore any these titles in the chat history.
|
||||
- If there is nothing: it means you are accidentally stopped. Please continue your work.
|
||||
- Read `Copilot_Planning.md` througly, it is highly possibly that you were working on the request described in the last section in `# UPDATES`.
|
||||
|
||||
### Create new Document (only when "# Problem" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Problem" in the LATEST chat message
|
||||
I am starting a fresh new request.
|
||||
|
||||
- Add an empty `# UPDATES` section after `# !!!PLANNING!!!`.
|
||||
- You are going to complete a more detailed planning document according to `Copilot_Task.md`.
|
||||
|
||||
### Update current Document (only when "# Update" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Update" in the LATEST chat message
|
||||
I am going to propose some change to `Copilot_Planning.md`.
|
||||
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# EXECUTION PLAN`).
|
||||
- Follow my update to change the planning document.
|
||||
|
||||
## Step 2. Understand the Goal and Quality Requirement
|
||||
|
||||
- You need to write complete two main sections in `Copilot_Planning.md`, an improvement plan and a test plan.
|
||||
- **Improvement Plan**:
|
||||
- Read through and understand the task in `Copilot_Task.md`.
|
||||
- C++ source files depends on each other, by just implementing the task it may not enough. Find out what will be affected.
|
||||
- Propose any code change you would like to do. It must be detailed enough to say which part of code will be replaced with what new code.
|
||||
- Explain why you want to make these changes.
|
||||
- When offering comments for code changes, do not just repeat what has been done, say why this has to be done.
|
||||
- If the code is simple and obvious, no comment is needed. Actually most of the code should not have comments.
|
||||
- Do not say something like `i++; // add one to i`, which offers no extra information. Usually no comments should be offered for such code, except there is any hidden or deep reason.
|
||||
- **Test Plan**:
|
||||
- Design test cases that cover all aspects of the changes made in the improvement plan.
|
||||
- Ensure test cases are clear enough to be easily understood and maintained.
|
||||
- Carefully think about corner cases to cover.
|
||||
- For refactoring work, existing test cases might have already covered most of the scenarios. Carefully review them and only add new test cases if necessary.
|
||||
- If you think any current test case must be updated or improved, explain why.
|
||||
- Read through and understand the task in `Copilot_Task.md`.
|
||||
|
||||
### Tips for a Feature Planning Task
|
||||
|
||||
- C++ source files depends on each other, by just implementing the task it may not enough. Find out what will be affected.
|
||||
- Propose any code change you would like to do. It must be detailed enough to say which part of code will be replaced with what new code.
|
||||
- Explain why you want to make these changes.
|
||||
- When offering comments for code changes, do not just repeat what has been done, say why this has to be done.
|
||||
- If the code is simple and obvious, no comment is needed. Actually most of the code should not have comments.
|
||||
- Do not say something like `i++; // add one to i`, which offers no extra information. Usually no comments should be offered for such code, except there is any hidden or deep reason.
|
||||
|
||||
### Tips for a Test Planning Task
|
||||
|
||||
- Design test cases that cover all aspects of the changes made in the improvement plan.
|
||||
- Ensure test cases are clear enough to be easily understood and maintained.
|
||||
- Carefully think about corner cases to cover.
|
||||
- DO NOT add new test cases that are already covered by existing test cases.
|
||||
|
||||
## Step 3. Finish the Document
|
||||
|
||||
@@ -88,9 +100,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
|
||||
50
.github/prompts/win-3-summarizing.prompt.md
vendored
50
.github/prompts/win-3-summarizing.prompt.md
vendored
@@ -6,41 +6,50 @@
|
||||
## Goal and Constraints
|
||||
|
||||
- Your goal is to finish an execution document in `Copilot_Execution.md` according to `Copilot_Task.md` and `Copilot_Planning.md`.
|
||||
- You are only allowed to update `Copilot_Execution.md`.
|
||||
- You are not allowed to modify any other files.
|
||||
- The phrasing of the request may look like asking for code change, but your actual work is to write the design document.
|
||||
|
||||
## Copilot_Execution.md Structure
|
||||
|
||||
- `# !!!EXECUTION!!!`: This file always begin with this title.
|
||||
- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
|
||||
- `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
|
||||
- `# IMPROVEMENT PLAN`.
|
||||
- `# TEST PLAN`.
|
||||
- `# EXECUTION PLAN`.
|
||||
- `# FIXING ATTEMPTS`.
|
||||
|
||||
## Step 1. Identify the Problem
|
||||
|
||||
- The design document is in `Copilot_Task.md`, the planning document is in `Copilot_Planning.md`.
|
||||
- Find `# Update` in the LATEST chat message. Ignore any `# Update` in the chat history.
|
||||
- If there is an `# Update` section: it means I am going to propose some change to `Copilot_Execution.md` and the source code together.
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# IMPROVEMENT PLAN`).
|
||||
- Follow my update to change the execution document.
|
||||
- If there is nothing:
|
||||
- If `Copilot_Execution.md` only has a title, you are on a fresh start.
|
||||
- Add an empty `# UPDATES` section after the title, if it does not already exist.
|
||||
- If there is a `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while changing the source code. Please continue your work.
|
||||
- If there is no `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while finishing the document. Please continue your work.
|
||||
- Find `# Problem` or `# Update` in the LATEST chat message.
|
||||
- Ignore any these titles in the chat history.
|
||||
- If there is nothing:
|
||||
- If there is a `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while changing the source code. Please continue your work.
|
||||
- If there is no `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while finishing the document. Please continue your work.
|
||||
|
||||
### Create new Document (only when "# Problem" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Problem" in the LATEST chat message
|
||||
I am starting a fresh new request.
|
||||
|
||||
- Add an empty `# UPDATES` section after `# !!!EXECUTION!!!`.
|
||||
- You are going to complete an execution document according to `Copilot_Planning.md`.
|
||||
|
||||
### Update current Document (only when "# Update" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Update" in the LATEST chat message
|
||||
I am going to propose some change to `Copilot_Execution.md`.
|
||||
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# EXECUTION PLAN`).
|
||||
- Follow my update to change the execution document.
|
||||
|
||||
## Step 2. Finish the Document
|
||||
|
||||
- Your need to summary code change in `Copilot_Execution.md`.
|
||||
- All changes you need to made is already in `Copilot_Planning.md`, but it contains many explanations.
|
||||
- Read `Copilot_Planning.md`, copy the following parts to `Copilot_Execution.md`:
|
||||
- `# IMPROVEMENT PLAN`
|
||||
- Copy EVERY code block exactly as written
|
||||
- If Planning has 1000 lines of test code, Execution must have those same 1000 lines
|
||||
- Remove only the explanatory text between code blocks
|
||||
- Keep ALL actual code
|
||||
- `# TEST PLAN`
|
||||
- `# EXECUTION PLAN`
|
||||
- Copy EVERY code block exactly as written
|
||||
- If Planning has 1000 lines of test code, Execution must have those same 1000 lines
|
||||
- Remove only the explanatory text between code blocks
|
||||
@@ -54,6 +63,7 @@
|
||||
- Each code block only contain consecutive code to be written to the file.
|
||||
- If the original code block contains metadata, do not include it.
|
||||
- If the original code block contains code change in multiple places or even multiple files, split it.
|
||||
- If the original code block omits surrounding code that is necessary to understand the change, expand it to complete.
|
||||
|
||||
## Step 3. Document Quality Check List
|
||||
|
||||
@@ -87,9 +97,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
|
||||
101
.github/prompts/win-4-execution.prompt.md
vendored
101
.github/prompts/win-4-execution.prompt.md
vendored
@@ -1,29 +1,43 @@
|
||||
# Execution
|
||||
|
||||
- Checkout `Accessing Log Files and PowerShell Scripts` for context about mentioned `*.md` and `*.ps1` files.
|
||||
- All `*.md` and `*.ps1` files should already be existing, you should not create any new files.
|
||||
|
||||
## Goal and Constraints
|
||||
|
||||
- You are going to apply changes on the source code as well following `Copilot_Execution.md`.
|
||||
- You are going to apply changes to the source code following `Copilot_Execution.md`.
|
||||
|
||||
## Copilot_Execution.md Structure
|
||||
|
||||
- `# !!!EXECUTION!!!`: This file always begin with this title.
|
||||
- `# UPDATES`:
|
||||
- `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
|
||||
- `# IMPROVEMENT PLAN`.
|
||||
- `# TEST PLAN`.
|
||||
- `# EXECUTION PLAN`.
|
||||
- `# FIXING ATTEMPTS`.
|
||||
|
||||
## Step 1. Identify the Problem
|
||||
|
||||
- The execution document is in `Copilot_Execution.md`
|
||||
- Find `# Update` in the LATEST chat message. Ignore any `# Update` in the chat history.
|
||||
- If there is an `# Update` section: it means I am going to propose some change to `Copilot_Execution.md` and the source code together.
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- Follow my update to change the execution document and the source code.
|
||||
- If there is nothing:
|
||||
- Apply all code changes in `Copilot_Execution.md` to the source code.
|
||||
- Make sure indentation and line breaks are applied correctly, following the same style in the target file.
|
||||
- After applying each step in `Copilot_Execution.md`, mark the step as completed by appending `[DONE]` after the step title. This allow you to find where you are if you are interrupted.
|
||||
- Find `# Update` in the LATEST chat message.
|
||||
- Ignore any these titles in the chat history.
|
||||
|
||||
### Execute the Plan (only when no title appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is any title in the LATEST chat message
|
||||
I am starting a fresh new request.
|
||||
|
||||
- Apply all code changes in `Copilot_Execution.md` to the source code.
|
||||
- Make sure indentation and line breaks are applied correctly, following the same style in the target file.
|
||||
- After applying each step in `Copilot_Execution.md`, mark the step as completed by appending `[DONE]` after the step title. This allow you to find where you are if you are interrupted.
|
||||
|
||||
### Update the Source Code and Document (only when "# Update" appears in the LATEST chat message)
|
||||
|
||||
Ignore this section if there is no "# Update" in the LATEST chat message
|
||||
I am going to propose some change to the source code.
|
||||
|
||||
- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# UPDATES` section, with a new sub-section `## UPDATE`.
|
||||
- Follow my update to change the source code.
|
||||
- Update the document to keep it consistent with the source code.
|
||||
|
||||
## Step 2. Make Sure the Code Compiles but DO NOT Run Unit Test
|
||||
|
||||
@@ -87,9 +101,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
@@ -115,6 +127,11 @@ You will find the `TaskLogs` project in the current solution, which should conta
|
||||
- The only source of trust is the raw output of the compiler.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Build.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- A temporary file `Build.log.unfinished` is created during building. It will be automatically deleted as soon as the building finishes . If you see this file, it means the building is not finished yet.
|
||||
- When build succeeds, the last several lines will show the following 3 lines, otherwise there are either warnings or errors. You can check the last 10 lines to make sure if build succceeded:
|
||||
- "Build succeeded."
|
||||
- "0 Warning(s)"
|
||||
- "0 Error(s)"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Executing Unit Test
|
||||
@@ -127,6 +144,60 @@ You will find the `TaskLogs` project in the current solution, which should conta
|
||||
- The only source of trust is the raw output of the unit test process.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Execute.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- When all test cases pass, there will be a summarizing about how many test cases are executed. Otherwise it crashed at the last showing test case.
|
||||
- A temporary file `Execute.log.unfinished` is created during testing. It will be automatically deleted as soon as the testing finishes. If you see this file, it means the testing is not finished yet.
|
||||
- When all test case passes, the last several lines will show the following 2 lines, otherwise it crashed at the last showing test case. You can check the last 5 lines to make sure if all test cases passed:
|
||||
- "Passed test files: X/X"
|
||||
- "Passed test cases: Y/Y"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Understanding the Building Tools
|
||||
|
||||
**WARNING**: Information offered in this section is for background knowledge only. You should always run `Build Unit Tests` and `Run Unit Tests` instead of running these scripts or calling msbuild or other executable by yourself.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
`SOLUTION-ROOT` is the folder containing the solution file.
|
||||
`PROJECT-NAME` is the name of the project.
|
||||
|
||||
When verifying test projects on Windows, msbuild is used to build a solution (`*.sln`) file.
|
||||
A solution contains many project (`*.vcxproj`) files, a project generates an executable (`*.exe`) file.
|
||||
|
||||
The `Build Unit Tests` task calls msbuild to build the only solution which contains all test cases.
|
||||
Inside the task, it runs `copilotBuild.ps1`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotBuild.ps1
|
||||
```
|
||||
|
||||
The `Run Unit Tests` task runs all generated *.exe file for each *.vcxproj that is created for test cases.
|
||||
To run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotExecute.ps1 -Executable PROJECT-NAME
|
||||
```
|
||||
|
||||
Test cases are organized in multiple test files.
|
||||
In `PROJECT-NAME\PROJECT-NAME.vcxproj.user` there is a filter, when it is effective, you will see filtered test files marked with `[SKIPPED]` in `Execute.log`.
|
||||
The filter is defined in this XPath: `/Project/PropertyGroup@Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"/LocalDebuggerCommandArguments`.
|
||||
The filter is effective only when the file exists and the element exists with one or multiple `/F:FILE-NAME.cpp`, listing all test files to execute, unlited files are skipped.
|
||||
But if the element exists but there is no `/F:FILE-NAME.cpp`, it executes all test files, non is skipped.
|
||||
|
||||
**IMPORTANT**:
|
||||
|
||||
ONLY WHEN test files you want to run is skipped, you can update the filter to activate it. This would typically happen when:
|
||||
- A new test file is added.
|
||||
- A test file is renamed.
|
||||
|
||||
You can clean up the filter to remove unrelated files, that is either not existing or it is totally unrelated to the current task you are working.
|
||||
If the current task does not work on that test file, but it tests closely related topic, you should better keep it in the list.
|
||||
|
||||
DO NOT delete this *.vcxproj.user file.
|
||||
DO NOT clean the filter (aka delete all `/FILE-NAME.cpp`) by yourself. I put a filter there because running everything is slow and unnecessary for the current task.
|
||||
|
||||
### Unit Test Project Structure
|
||||
|
||||
In this project, the only unit test solution is `REPO-ROOT\Test\UnitTest\UnitTest.sln` therefore `SOLUTION-ROOT` is `REPO-ROOT\Test\UnitTest`.
|
||||
Here is the list of all unit test projects under this solution and they are executed in the following order:
|
||||
- UnitTest
|
||||
|
||||
|
||||
65
.github/prompts/win-5-verifying.prompt.md
vendored
65
.github/prompts/win-5-verifying.prompt.md
vendored
@@ -108,9 +108,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
@@ -136,6 +134,11 @@ You will find the `TaskLogs` project in the current solution, which should conta
|
||||
- The only source of trust is the raw output of the compiler.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Build.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- A temporary file `Build.log.unfinished` is created during building. It will be automatically deleted as soon as the building finishes . If you see this file, it means the building is not finished yet.
|
||||
- When build succeeds, the last several lines will show the following 3 lines, otherwise there are either warnings or errors. You can check the last 10 lines to make sure if build succceeded:
|
||||
- "Build succeeded."
|
||||
- "0 Warning(s)"
|
||||
- "0 Error(s)"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Executing Unit Test
|
||||
@@ -148,6 +151,60 @@ You will find the `TaskLogs` project in the current solution, which should conta
|
||||
- The only source of trust is the raw output of the unit test process.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Execute.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- When all test cases pass, there will be a summarizing about how many test cases are executed. Otherwise it crashed at the last showing test case.
|
||||
- A temporary file `Execute.log.unfinished` is created during testing. It will be automatically deleted as soon as the testing finishes. If you see this file, it means the testing is not finished yet.
|
||||
- When all test case passes, the last several lines will show the following 2 lines, otherwise it crashed at the last showing test case. You can check the last 5 lines to make sure if all test cases passed:
|
||||
- "Passed test files: X/X"
|
||||
- "Passed test cases: Y/Y"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Understanding the Building Tools
|
||||
|
||||
**WARNING**: Information offered in this section is for background knowledge only. You should always run `Build Unit Tests` and `Run Unit Tests` instead of running these scripts or calling msbuild or other executable by yourself.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
`SOLUTION-ROOT` is the folder containing the solution file.
|
||||
`PROJECT-NAME` is the name of the project.
|
||||
|
||||
When verifying test projects on Windows, msbuild is used to build a solution (`*.sln`) file.
|
||||
A solution contains many project (`*.vcxproj`) files, a project generates an executable (`*.exe`) file.
|
||||
|
||||
The `Build Unit Tests` task calls msbuild to build the only solution which contains all test cases.
|
||||
Inside the task, it runs `copilotBuild.ps1`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotBuild.ps1
|
||||
```
|
||||
|
||||
The `Run Unit Tests` task runs all generated *.exe file for each *.vcxproj that is created for test cases.
|
||||
To run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotExecute.ps1 -Executable PROJECT-NAME
|
||||
```
|
||||
|
||||
Test cases are organized in multiple test files.
|
||||
In `PROJECT-NAME\PROJECT-NAME.vcxproj.user` there is a filter, when it is effective, you will see filtered test files marked with `[SKIPPED]` in `Execute.log`.
|
||||
The filter is defined in this XPath: `/Project/PropertyGroup@Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"/LocalDebuggerCommandArguments`.
|
||||
The filter is effective only when the file exists and the element exists with one or multiple `/F:FILE-NAME.cpp`, listing all test files to execute, unlited files are skipped.
|
||||
But if the element exists but there is no `/F:FILE-NAME.cpp`, it executes all test files, non is skipped.
|
||||
|
||||
**IMPORTANT**:
|
||||
|
||||
ONLY WHEN test files you want to run is skipped, you can update the filter to activate it. This would typically happen when:
|
||||
- A new test file is added.
|
||||
- A test file is renamed.
|
||||
|
||||
You can clean up the filter to remove unrelated files, that is either not existing or it is totally unrelated to the current task you are working.
|
||||
If the current task does not work on that test file, but it tests closely related topic, you should better keep it in the list.
|
||||
|
||||
DO NOT delete this *.vcxproj.user file.
|
||||
DO NOT clean the filter (aka delete all `/FILE-NAME.cpp`) by yourself. I put a filter there because running everything is slow and unnecessary for the current task.
|
||||
|
||||
### Unit Test Project Structure
|
||||
|
||||
In this project, the only unit test solution is `REPO-ROOT\Test\UnitTest\UnitTest.sln` therefore `SOLUTION-ROOT` is `REPO-ROOT\Test\UnitTest`.
|
||||
Here is the list of all unit test projects under this solution and they are executed in the following order:
|
||||
- UnitTest
|
||||
|
||||
|
||||
61
.github/prompts/win-code.prompt.md
vendored
61
.github/prompts/win-code.prompt.md
vendored
@@ -88,6 +88,11 @@
|
||||
- The only source of trust is the raw output of the compiler.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Build.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- A temporary file `Build.log.unfinished` is created during building. It will be automatically deleted as soon as the building finishes . If you see this file, it means the building is not finished yet.
|
||||
- When build succeeds, the last several lines will show the following 3 lines, otherwise there are either warnings or errors. You can check the last 10 lines to make sure if build succceeded:
|
||||
- "Build succeeded."
|
||||
- "0 Warning(s)"
|
||||
- "0 Error(s)"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Executing Unit Test
|
||||
@@ -100,6 +105,60 @@
|
||||
- The only source of trust is the raw output of the unit test process.
|
||||
- It is saved to `REPO-ROOT/.github/TaskLogs/Execute.log`. `REPO-ROOT` is the root folder of the repo.
|
||||
- Wait for the task to finish before reading the log file. DO NOT HURRY.
|
||||
- When all test cases pass, there will be a summarizing about how many test cases are executed. Otherwise it crashed at the last showing test case.
|
||||
- A temporary file `Execute.log.unfinished` is created during testing. It will be automatically deleted as soon as the testing finishes. If you see this file, it means the testing is not finished yet.
|
||||
- When all test case passes, the last several lines will show the following 2 lines, otherwise it crashed at the last showing test case. You can check the last 5 lines to make sure if all test cases passed:
|
||||
- "Passed test files: X/X"
|
||||
- "Passed test cases: Y/Y"
|
||||
- DO NOT TRUST related tools Visual Studio Code offers you, like `get_errors` or `get_task_output`, etc.
|
||||
|
||||
## Understanding the Building Tools
|
||||
|
||||
**WARNING**: Information offered in this section is for background knowledge only. You should always run `Build Unit Tests` and `Run Unit Tests` instead of running these scripts or calling msbuild or other executable by yourself.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
`SOLUTION-ROOT` is the folder containing the solution file.
|
||||
`PROJECT-NAME` is the name of the project.
|
||||
|
||||
When verifying test projects on Windows, msbuild is used to build a solution (`*.sln`) file.
|
||||
A solution contains many project (`*.vcxproj`) files, a project generates an executable (`*.exe`) file.
|
||||
|
||||
The `Build Unit Tests` task calls msbuild to build the only solution which contains all test cases.
|
||||
Inside the task, it runs `copilotBuild.ps1`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotBuild.ps1
|
||||
```
|
||||
|
||||
The `Run Unit Tests` task runs all generated *.exe file for each *.vcxproj that is created for test cases.
|
||||
To run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`
|
||||
|
||||
```
|
||||
cd SOLUTION-ROOT
|
||||
& REPO-ROOT\.github\TaskLogs\copilotExecute.ps1 -Executable PROJECT-NAME
|
||||
```
|
||||
|
||||
Test cases are organized in multiple test files.
|
||||
In `PROJECT-NAME\PROJECT-NAME.vcxproj.user` there is a filter, when it is effective, you will see filtered test files marked with `[SKIPPED]` in `Execute.log`.
|
||||
The filter is defined in this XPath: `/Project/PropertyGroup@Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"/LocalDebuggerCommandArguments`.
|
||||
The filter is effective only when the file exists and the element exists with one or multiple `/F:FILE-NAME.cpp`, listing all test files to execute, unlited files are skipped.
|
||||
But if the element exists but there is no `/F:FILE-NAME.cpp`, it executes all test files, non is skipped.
|
||||
|
||||
**IMPORTANT**:
|
||||
|
||||
ONLY WHEN test files you want to run is skipped, you can update the filter to activate it. This would typically happen when:
|
||||
- A new test file is added.
|
||||
- A test file is renamed.
|
||||
|
||||
You can clean up the filter to remove unrelated files, that is either not existing or it is totally unrelated to the current task you are working.
|
||||
If the current task does not work on that test file, but it tests closely related topic, you should better keep it in the list.
|
||||
|
||||
DO NOT delete this *.vcxproj.user file.
|
||||
DO NOT clean the filter (aka delete all `/FILE-NAME.cpp`) by yourself. I put a filter there because running everything is slow and unnecessary for the current task.
|
||||
|
||||
### Unit Test Project Structure
|
||||
|
||||
In this project, the only unit test solution is `REPO-ROOT\Test\UnitTest\UnitTest.sln` therefore `SOLUTION-ROOT` is `REPO-ROOT\Test\UnitTest`.
|
||||
Here is the list of all unit test projects under this solution and they are executed in the following order:
|
||||
- UnitTest
|
||||
|
||||
|
||||
4
.github/prompts/win-kb-design.prompt.md
vendored
4
.github/prompts/win-kb-design.prompt.md
vendored
@@ -126,9 +126,7 @@ This guidance is for accessing following files mentioned in this instruction:
|
||||
- `Build.log`
|
||||
- `Execute.log`
|
||||
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder.
|
||||
|
||||
`REPO-ROOT` is the root folder of the repo.
|
||||
They are in the `REPO-ROOT/.github/TaskLogs` folder. `REPO-ROOT` is the root folder of the repo.
|
||||
|
||||
## If you are running in Visual Studio
|
||||
|
||||
|
||||
Reference in New Issue
Block a user