mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-23 00:26:36 +00:00
enhancing clarity in research assessment and problem description sections.
some files rename
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -1,22 +1,12 @@
|
||||
# Create initial structure
|
||||
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
Located here: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
||||
|
||||
## Restrictions for the input data
|
||||
`@_docs/00_problem/restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution spec:
|
||||
`@_docs/01_solution/solution.md`
|
||||
|
||||
## Components with Features specs
|
||||
`@_docs/02_components`
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`.
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`.
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components with Features specifications: `@_docs/02_components`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
@@ -29,7 +19,32 @@
|
||||
- component's interfaces
|
||||
- empty implementations
|
||||
- helpers - empty implementations or interfaces
|
||||
- add README.md, describe the project by @_docs/01_solution/solution.md
|
||||
- add README.md, describe the project by @_docs/01_solution/solution.md
|
||||
- Create a separate project for the integration tests
|
||||
|
||||
## Example
|
||||
The structure should roughly looks like this:
|
||||
-
|
||||
- api
|
||||
- components
|
||||
- component1_folder
|
||||
- component2_folder
|
||||
- ...
|
||||
- db
|
||||
- helpers
|
||||
- models
|
||||
- tests
|
||||
- unit_test1_project1_folder
|
||||
- unit_test2_project2_folder
|
||||
...
|
||||
- integration_tests_folder
|
||||
- test data
|
||||
- test01_file
|
||||
- test02_file
|
||||
...
|
||||
|
||||
Also it is possible that some semantically coherent components (or 1 big component) would be in its own project or project folder
|
||||
Could be common layer or project consisting of all the interfaces (for C# or Java), or each interface in each component's folder (python) - depending on the language common conventions
|
||||
|
||||
## Notes
|
||||
- Follow SOLID principles
|
||||
|
||||
@@ -3,40 +3,29 @@
|
||||
## Input parameter
|
||||
component_folder
|
||||
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
Located here: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
||||
|
||||
## Restrictions for the input data
|
||||
`@_docs/00_problem/restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution:
|
||||
`@_docs/01_solution/solution.md`
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`.
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`.
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
|
||||
- Read carefully initial data and component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
|
||||
- Read carefully all the component features in the component_folder: `@_docs/02_components/[##]_[component_name]/[##].[##]_feature_[feature_name]`
|
||||
- Investgate in internet what are the best way and tools to implement component and its features
|
||||
- During the investigation is is possible that found solutions required architecturally reorganization of the features. It is ok, propose that and if user agrees, include reorganization in the build feature plan. Also it is possible that interface could be changed or even removed or added new one. It is ok.
|
||||
- Analyze the existing codebase and get full context for the component's implementation
|
||||
- Make sure each feature is connected and communicated properly with other features and existing code
|
||||
- If component has dependency on another one, create temporary mock for the dependency
|
||||
- Create unit tests from the Test cases description, run it and make sure the result is a success
|
||||
- Create integration test for the feature, run and make sure the result is a success
|
||||
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
|
||||
- Include in the plan code assesment
|
||||
|
||||
- For each feature:
|
||||
- Implement the feature
|
||||
- Implement all unit tests from the Test cases description, add checks test results to the plan steps
|
||||
- Implement all integration tests for the feature, add check test results to the plan steps. Analyze existing tests, and decide whether to create new one or add to existing
|
||||
- Add to the implementation plan description of all component's integration tests, add check test results to the plan steps
|
||||
|
||||
## Notes
|
||||
- Follow SOLID principles
|
||||
- Follow KISS principle. Dumb code - smart data.
|
||||
- Follow DRY principles, but do not overcomplicate things, if code repeats sometimes, it is ok if that would be simpler
|
||||
- Follow conventions and rules of the project's programming language
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# Implement tests by spec
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`.
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`.
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Tests specifications: `@_docs/02_tests`
|
||||
|
||||
## Role
|
||||
You are a professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully all the initial data and understand whole system goals
|
||||
- Check that a separate project in a separate folder is existing (should be generated by @3.05_implement_initial_structure.md)
|
||||
- For each test description:
|
||||
- Prepare all the data necessary for testing, or check it is already exists
|
||||
- Check existing integration tests and if a similar test is already exists, update it
|
||||
- Implement the test by specification
|
||||
- Run system and integration tests and in 2 separate docker containers
|
||||
- Fix all problems if tests failed until we got a successful result. In case if one or more tests was failed due to missing data from user or API or other system, ask it from developer.
|
||||
- Repeat test cycle until no failed tests, iteratively fixing found bugs. Ask user for an additional information if something new appears
|
||||
- Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
## Notes
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
Reference in New Issue
Block a user