66 lines
4.4 KiB
Markdown
66 lines
4.4 KiB
Markdown
## Workitem implementation
|
|
|
|
Your task is to understand the business requirements of the work item, with respect to the existing codebase,
|
|
and rephrase them as test specifications in the cucumber format.
|
|
|
|
The requirements of the work item itself must NOT be implemented at this stage.
|
|
|
|
- Work items for which the cucumber file already exists should be checked
|
|
- If the feature file appears consistent with the work item, it can be skipped and your task is done.
|
|
- If the feature file appears uncomplete, it can be updated
|
|
- Avoid updating scenarios that are still consistent with the work item.
|
|
- Prefer adding new scenarios for features omitted in the current feature file.
|
|
- Inactive work items should have their feature file deleted.
|
|
- Updates which required filesystem changes should be committed before completing the task.
|
|
If no changes was required, commit should be skipped.
|
|
The commit must contain AT MOST a single file: the .feature file.
|
|
|
|
IMPORTANT:
|
|
- Start by understanding the work item business requirements with respect to the existing codebase.
|
|
- Use the filesystem functions at your disposal to navigate the codebase.
|
|
- Identify the resources involved and whether they exist or not in the codebase
|
|
- Investigate the involved resources for their lifecycle existing business logic implemented in the codebase.
|
|
- Identify how the requirements of the work item will impact the existing codebase
|
|
- Then, identify test cases that could be used to guarantee proper implementation of the business requirements.
|
|
- Test the happy flow, but also test the error cases.
|
|
- Then, describe the test specs complying with the work item as a cucumber feature spec file in the
|
|
`nitro-it/src/test/resources/workitems/` folder.
|
|
- Use the workitem prompt file name as the feature file name.
|
|
- Add comments in the feature file indicating
|
|
- The date/time/execution info of the job that created the work item
|
|
- The work item prompt file in this directory
|
|
- The jira ticket number, and a link to the jira ticket if applicable.
|
|
|
|
- DO NOT modify the codebase: If some API models, or endpoints are missing, do NOT add them.
|
|
- DO NOT use ids, pseudo-identifiers, assumed values etc. Instead, inspect the codebase to
|
|
understand the lifecycle of the resources.
|
|
- DO NOT use 'Given a document exists with id XXX', but DO USE 'Given a document is uploaded'
|
|
- DO NOT use 'Given a customer exists with id XXX', but USE 'Given a customer is created'
|
|
- Use business requirements. Try to write test cases focusing on high-level expectations. Write more specific test
|
|
specs if it appears warranted (specifics of the work item, sensitive or complex logic involved, etc.)
|
|
- DO NOT use 'Given this resource has status XXX, Then', but prefer 'Given this resource has been created, And that
|
|
operation A has been performed on it, And that operation B has been performed on it, Then'
|
|
|
|
- This project contains the following modules:
|
|
- nitro-domain: contains the jpa domain entities
|
|
- nitro-domain-api: contains the api model, controller interfaces, and the openapi specification. The api resource
|
|
names are prefixed with "Ws"
|
|
- nitro-it: contains the integration tests
|
|
- nitro-core-services: contains the core services implementations
|
|
- nitro-domain-rest and nitro-domain-ws-utils: contains the api implementation
|
|
|
|
- This project deals with state machines for documents, transactions, statements, field requests.
|
|
- "CustomerDocument" and "CustomerTransaction" are the main resources, each composed in part of an AccountingData.
|
|
- The hierarchy of tenancy has two levels: Trustee and Customer
|
|
- Explore DocumentStatus, DocumentTransition enums to grasp the document state machine
|
|
- Explore TestDocumentSortingService, TestDocumentIndexingService for utilities for sorting and indexing documents
|
|
during tests
|
|
- Explore TransactionStatus enum, TransactionStatusUpdateSingleton to grasp the transaction state machine
|
|
- Explore FieldIdentificationRequestStatus enum, FieldIdentificationValueStatus enum,
|
|
FieldIdentificationRequestStatusUpdateSingleton to grasp the field request state machine
|
|
- Explore FinancialAccountStatementStatus enum to grasp the financial account statement state machine
|
|
|
|
- Inspect the existing business resources using the available filesystem functions
|
|
- look in nitro-domain for the domain entities
|
|
- look in nitro-core-services for the business services
|