search

SelwynChan / HelloWorld

My first Git Repository
0 stars 0 forks source link

Req #17

Open SelwynChan opened 1 year ago

SelwynChan commented 1 year ago

The DS-OL also adopt an event-based approach to reconstruct the order lifecycles. Events which are to be recorded in the DS-OL format are mainly the client-side events (e.g. client requests to place a new order, modify or cancel an order) and execution-related events (e.g. child order splits to Execution Venues and the executed trades)

The DS-OL require In-Scope Brokers to record Material Terms (i.e. minimum information) of an order and/or any changes to these terms throughout an order life cycle. Material Terms of an order shall include, but are not limited to:  Order price  Order quantity  Order side  Order type and instructions  Time in force (or time validity)  Order capacity  Client identification  Algorithmic order instructions (i.e. algorithm parameters according to the In-Scope Broker’s system settings for algorithmic orders)  Aggregating information behind aggregated orders. In general, if any Material Terms of an order is modified, a corresponding modification event (Order Modify Event) should be recorded in the DS-OL format.

To reconstruct and report order life cycles under the DS-OL, an order life cycle is decomposed into various event types. They are: Order New, Order Modify, Order Cancel, Split New, Split Modify, Split Cancel, Execution, Execution Correction and Allocation. Separately there is also the Order Summary event which represents a summation of the life cycle after completion. Each of these events contains several data fields

The Order New event denotes the ’starting point’ of each order (for a single security name) received by the In-Scope Broker from a client. For an order which may exist within multiple trading systems or technology stacks within an In-Scope Broker, only one ONEW event is required. Hence for different business flows within the In-Scope Broker, this starting point can vary, and the In-Scope Broker needs to identify these starting points accordingly based on its own business flows Order New is a consolidated event capturing data from any of (1) the new order message or action, (2) acknowledgement or reject message, (3) order ticket record, and (4) any other client or market static data, if applicable. Orders received by an In-Scope Broker may be one of several different ’types’ of orders specifying different behaviours, such as price limitations, conditional logic and targeting a benchmark price, etc. The types of orders offered by InScope Brokers differ widely across organisations. To capture such instructions in a consistent manner, the orderType and orderInst fields are used where orderType categorises the order into one of several types as defined in the orderType enumerations and orderInst is a dictionary look-up value which maps the name of an order type or instruction (e.g., CD order) to its full name and/or detailed description as per the In-Scope Broker’s Reference Data Dictionary. Multiple instructions should be separated using '|'9 as a delimiter. E.g. 1) a 'special limit order' could have orderType=LMT and orderInst=special-limit; 2) a 'CD order, stay on bid-side only' could have orderType=MKT and orderInst=CD|stayonbid. The instruction string keys can be freely defined and should map to the In-Scope Broker’s Reference Data Dictionary. A filler value is required when not applicable. Orders received by In-Scope Brokers that remain in force for more than one day such as GTC, GTD, etc. are referred to as ’multi-day’ orders. When presenting multi-day orders, the LOID is required to remain unchanged during their life cycles, regardless of how multi-day orders are implemented in the InScope Broker’s systems (e.g., by automatically recreating a new order every business day or rolling over the same order to the next business day). The treatment of order quantities (orderQty) may differ across systems with respect to multi-day orders. To support systems which do not modify the original orderQty during the order life cycle, the nDayOrderQty field should be used to indicate the outstanding orderQty. The ’Order Capacity’ (orderCapacity) of a new order should indicate the intended trading or executing capacity of the order. E.g., if a client requests the In-Scope Broker to provide a guaranteed price (a guaranteed VWAP order for example), the orderCapacity should be ’Principal’ when it is recorded in the Order New event. If the orderCapacity changes (e.g. from agency to principal) after an order has been received, this should be recorded with an Order Modify event. In this case, individual Order and/or Split events will be denoted as agency or principal as the case may be, and in the Order Summary, the orderCapacity will be mixed (value ’AP’ which is only applicable in an Order Summary event). Aggregated orders (i.e., orders created in the In-Scope Broker’s trading system by consolidating similar orders into a single order to be handled collectively) should also be recorded using the Order New event with the list of constituent orders and their respective quantities captured using the aggregatedOrders field. Below is an example of how the aggregatedOrders field could be populated (comma separated table): clientID,logicalOrderID,orderQty,aggregratedOrders CLIENT-A,A01,1000 CLIENT-B,B01,2000 na,G01,3000,A01=1000|B01=2000

There are four client types defined in the DS-OL. When an In-Scope Broker provides agency trading services to a securities broker that is a group company, this entity is an ’internal (institutional)’ client (’INSI’), otherwise the entity is an ’external (institutional)’ client (’INSE’). A ’principal’ client (’PROP’) will typically be a business unit within an In-Scope Broker or a group company, such as a client facilitation or proprietary trading desk. Client type (’RETL’) is used for a retail client. In general, the clientID is a unique identifier used by the In-Scope Broker to refer to the immediate client from which the order is received. Where the immediate client might be trading on behalf of another client, i.e. the end client, this ’end client’ information is only required in some specific scenarios such as when an order is handled by multiple group companies and where the In-Scope Broker has knowledge of the end client’s identity. In the DS-OL, both request and response part of an event are stored in the same record, and even if a trading system provides no message level response to a request, the eventResponseType field should still be populated with a logical response. I.e. As an order is accepted or rejected by an InScope Broker’s trading system, either an ’ACK’ or ’REJ’ value should be set in the eventResponseType field. In case an event does not have any logical response, e.g. if an order was sent to an Execution Venue but a response was never received (e.g., when the Execution Venue went down), this can be recorded with a ’No Response’ (’null’) value in the eventResponseType field. In case of an Order Modify or Order Cancel event, if the modification or cancellation is initiated by the In-Scope Broker on behalf of the client, this is recorded with an ’Unsolicited’ (’UNS’) value in the eventResponseType field. Similarly, in a Split Modify or Split Cancel event, if the modification or cancellation of a split is initiated by an Execution Venue, the same principle applies. The Order Modify event should generally be used when any Material Term of an order is modified. When multiple Material Terms of an order are modified in a single operation, only one Order Modify event is required. However, if multiple modify operations are performed separately on the same event, these Order Modify events should be recorded separately. For example, if a client order was originally traded as ’agency’, but later the client requested for a guaranteed price of the whole order, the intended trading capacity should be modified to ’principal’ using an Order Modify event As Execution Venue is not one of the Material Terms, no Order Modify event is required if an order is rerouted. E.g., if a client order was originally sent to an exchange, but later cancelled by an In-Scope Broker’s trader and crossed in an ALP, such changes should be recorded as Split events. The Order Cancel events should be used whenever an order is cancelled. For mass cancel requests to exchanges in exception scenarios (e.g. a Kill Switch or Cancel on Disconnect), although these requests are not on order level, the result is that individual exchange-side orders are cancelled back to the InScope Broker’s trading systems. Thus, these events should be recorded using Order Cancel events on the client orders as unsolicited cancels. A ’Mass Cancelled’ flag (massCancelled) should also be used if the In-Scope Broker can provide this indicator. The Split New event denotes a ’child order split’ of a parent order. Throughout the order life cycle, regardless of the number of times the order is split while traversing through trading systems or technology stacks, only the order splits that may receive executions from Execution Venues are required to be recorded with the Split New event. For the avoidance of doubt, child order splits that are eventually not executed are still required to be recorded. Child order splits for Internalised Trades are not strictly required if the orderCapacity of the child order split is the same as the parent order’s orderCapacity. For order handling which does not typically split an order into smaller orders and/or change any Material Terms before sending the order to an exchange for execution, a Split New event is not required. The Split Modify event should be used when any Material Term of a child order split is modified. An example of a Split Modify event would be when an Algo child order split sent to an exchange has its order price modified by the Algo due to market movements. The Split Cancel event should be used when a corresponding child order split is cancelled, including unsolicited cancellations by an exchange. The Execution event denotes a ’trade report’ for each client order from an Execution Venue. Execution events should be linked to corresponding Order events via LOID. Linkage to the immediate order or split order IDs is not required. If trade details are subsequently amended or cancelled, this should be recorded using an Execution Correction event Internalised Trades refer to:  Trades that are executed internally, such as by internal crosses, ALP matches and manual fills; or  Post-execution allocations of aggregated orders For these executions, the internalisedTrade field is set as ‘true’. When an order is executed by crossing orders between agency clients, either through an ALP or via manual internal crossing, the crossTrade field should be set as ‘true’ with executionCapacity set as ‘XA - Cross as Agency’. The counterpartyID field should indicate the actual counterparty of the cross in the corresponding Execution events on both sides. For Internalised Trades filled by the In-Scope Broker’s own inventory, this should be denoted by an Execution event with the internalisedTrade field set as ‘true’. The crossTrade field should be set as ‘true’ with executionCapacity set as ’XP - Cross as Principal’. The tradeBookID field should indicate the internal book of the In-Scope Broker which has provided the inventory. Where orders have been aggregated and executed orders need to be allocated to the constituent client orders, the client-side executions should be denoted with internalisedTrade set as ‘true’. Also, the sourceExecVenue should provide the Execution Venue on which the market side executions have taken place. E.g. If the executionVenue field on an aggregated order shows XHKG, the executionVenue fields of the constituent orders should show the same. In the case of an Internalised Trade where the In-Scope Broker has assumed different types of execution capacity, the individual executions must be recorded separately. E.g., where a client order is partially filled by internal cross with an order from another agency client, the executionCapacity field should show XA; where this order is partially filled from the In-Scope Broker’s own inventory, the executionCapacity field should show XP. Odd lot or special lot fills are commonly provided to clients by In-Scope Brokers as Internalised Trades (internalisedTrade=true). In such cases, these trades should be recorded as principal cross trades (i.e., crossTrade=true, executionCapacity=XP), and with executionVenue=XOFF14, oddLotTrade=true. The orderCapacity field should however remain as ’A’ indicating that the intention of the order is to be traded as agency regardless of how that order is filled. In case an odd lot or special lot is filled via an exchange facility directly (e.g. semi-automatic matching for odd lot or special lot via HKEX), this should be recorded as an exchange execution, i.e. crossTrade=false, executionCapacity=A, executionVenue=XHKG, and with oddLotTrade=true. The Execution Correction event denotes the ’corrected’ execution details (i.e., executed price and/or quantity) on a summary basis. This event is applicable where the execution is either amended or cancelled and there should be only one single Execution Correction event per parent order which might consist of multiple child order splits and executions. When performing execution amendment or cancellation to an order, In-Scope Brokers should not present the workflow specifics illustrating how executions are corrected but only the outcome of a correction. i.e., regardless of whether a correction is performed by (i) directly amending one or more existing execution details, (ii) allocating the executions first to an In-Scope Broker’s error account and providing a new execution for the order, or (iii) via any other method. If a correction is performed more than one time, only the final correction of the day needs to be presented in the DS-OL format. There should be no additional Execution event for an order after the Execution Correction event. The Allocation event should be used for ’aggregated orders’ only. When an aggregated order is partially or fully filled, these fills shall be allocated to the constituent client orders. Allocation events are recorded after all the Execution events of an aggregated order, with direct linkage to the client orders’ LOID using allocToLOID, and showing allocated quantity in the allocQty field. One Allocation event refers to one client order’s allocation, hence multiple Allocation events are expected for each aggregated order The Order Summary event is not part of the configuration of an order life cycle. Instead it is created to provide a record of the end of day summary of an order primarily for ease of identification and validation. Unlike the other events, Order Summary events are not necessarily the events which occur within a front-office system. For each parent order completed within the same day, only one Order Summary event is required to provide information related to that order at the end of the order life cycle. Total executed quantity (totalExecutedQty) and averaged price (avgExecutedPrice) should be based on the final quantity and price to be settled with the client. For multi-day orders, however, an Order Summary is required which gives a summary of the multi-day order as of each corresponding end-of-day during its life cycle. The orderCapacity field in an Order Summary event allows additional value ’AP’ which can be used to indicate when a client order is intended to trade partially in an agency capacity and partially in a principal capacity. Order Summary events are not required on aggregated orders but are required on the constituent client orders.

SelwynChan commented 1 year ago

Test Case 1: Order New Event

Objective: Test the correct creation of an Order New event with all material terms.

Input:

Expected Result: The Order New event should be created with the following material terms:

Test Case 2: Order Modify Event

Objective: Test the correct creation of an Order Modify event when modifying the order price and order quantity.

Input:

Expected Result: The Order Modify event should be created with the following modified material terms:

Test Case 3: Time in Force Modification

Objective: Test the correct creation of an Order Modify event when modifying the time in force.

Input:

Expected Result: The Order Modify event should be created with the following modified material terms:

Test Case 4: Order Capacity Modification

Objective: Test the correct creation of an Order Modify event when modifying the order capacity.

Input:

Expected Result: The Order Modify event should be created with the following modified material terms:

Test Case 5: Aggregated Orders

Objective: Test the correct creation of an Order New event with aggregated orders.

Input:

Expected Result: The Order New event should be created with the following material terms:

Test Case 6: Multi-Day Orders

Objective: Test the correct handling of multi-day orders using the LOID and nDayOrderQty fields.

Input:

Expected Result: The Order New event and subsequent Order Modify events should maintain the same LOID throughout the order life cycle. The nDayOrderQty field should be updated to reflect the outstanding order quantity for each day:

SelwynChan commented 1 year ago

Test Case 7: Algorithmic Order Instructions

Objective: Test the correct creation of an Order New event with algorithmic order instructions.

Input:

Expected Result: The Order New event should be created with the following material terms:

Test Case 8: Order Cancel Event

Objective: Test the correct creation of an Order Cancel event.

Input:

Expected Result: The Order Cancel event should be created with the following material terms:

Test Case 9: Split New Event

Objective: Test the correct creation of a Split New event.

Input:

Expected Result: The Split New event should be created with the following material terms:

Test Case 10: Split Modify Event

Objective: Test the correct creation of a Split Modify event when modifying the split order quantity.

Input:

Expected Result: The Split Modify event should be created with the following modified material terms:

Test Case 11: Split Cancel Event

Objective: Test the correct creation of a Split Cancel event.

Input:

Expected Result: The Split Cancel event should be created with the following material terms:

Test Case 12: Execution Event

Objective: Test the correct creation of an Execution event.

Input:

Expected Result: The Execution event should be created with the following material terms:

Test Case 13: Execution Correction Event

Objective: Test the correct creation of an Execution Correction event.

Input:

Expected Result: The Execution Correction event should be created with the following material terms:

Test Case 14: Allocation Event

Objective: Test the correct creation of an Allocation event.

Input:

Expected Result: The Allocation event should be created with the following material terms:

Test Case 15: Order Summary Event

Objective: Test the correct creation of an Order Summary event after the completion of an order life cycle.

Input:

Expected Result: The Order Summary event should be created with the following material terms:

SelwynChan commented 1 year ago

Test Case 16: Client Types

Objective: Test the correct identification of client types.

Input:

  1. Internal (Institutional) client (INSI)
  2. External (Institutional) client (INSE)
  3. Principal client (PROP)
  4. Retail client (RETL)

Expected Result: The system should correctly identify and categorize each client type as follows:

  1. INSI: Internal (Institutional) client
  2. INSE: External (Institutional) client
  3. PROP: Principal client
  4. RETL: Retail client

Test Case 17: Event Response Type

Objective: Test the correct assignment of event response types.

Input:

  1. Order accepted: ACK
  2. Order rejected: REJ
  3. No response: null
  4. Unsolicited modification or cancellation: UNS

Expected Result: The system should correctly assign the corresponding event response type for each scenario:

  1. ACK: Order accepted
  2. REJ: Order rejected
  3. null: No response
  4. UNS: Unsolicited modification or cancellation

Test Case 18: Order Modify with Multiple Material Term Changes

Objective: Test the correct creation of an Order Modify event when multiple material terms of an order are modified in a single operation.

Input: (Refer to Test Case 1 for the original order)

Expected Result: The Order Modify event should be created with the following modified material terms:

Test Case 19: Order Rerouting without Material Term Changes

Objective: Test that no Order Modify event is required when an order is rerouted without any material term changes.

Input: (Refer to Test Case 1 for the original order)

Expected Result: No Order Modify event should be required since the execution venue is not a material term.

Test Case 20: Mass Cancelled Orders

Objective: Test the correct creation of Order Cancel events for mass cancelled orders.

Input: (Refer to Test Case 1 for the original order)

Expected Result: The Order Cancel event should be created with the following material terms:

Test Case 21: Child Order Split Not Executed

Objective: Test the correct creation of a Split New event for child order splits that are not executed.

Input:

Expected Result: The Split New event should be created with the following material terms:

Test Case 22: Split Modify for Algo Child Order

Objective: Test the correct creation of a Split Modify event when an algo child order split's order price is modified due to market movements.

Input:

Expected Result: The Split Modify event should be created with the following modified material terms:

Test Case 23: Execution Correction Event for Amended Trade Details

Objective: Test the correct creation of an Execution Correction event when trade details are amended.

Input:

Expected Result: The Execution Correction event should be created with the following material terms:

SelwynChan commented 1 year ago

Based on the provided specifications, I have outlined some test case scenarios for different situations related to Internalized Trades, Cross Trades, Odd Lot/Special Lot, Execution Correction, Allocation, and Order Summary events. These test cases can be used to validate your implementation based on the given requirements.

  1. Internalized Trades (Agency Cross)

    • Test Case 1: An order is executed by crossing orders between agency clients through an ALP.

      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XA
      • counterpartyID: Actual counterparty ID

    • Test Case 2: An order is executed by crossing orders between agency clients via manual internal crossing.

      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XA
      • counterpartyID: Actual counterparty ID

  2. Internalized Trades (Filled by In-Scope Broker's Inventory)

    • Test Case: An order is filled by the In-Scope Broker's own inventory.
      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XP
      • tradeBookID: In-Scope Broker's internal book

  3. Internalized Trades (Post-Execution Allocations)

    • Test Case: An aggregated order is allocated to the constituent client orders.
      • internalisedTrade: true
      • sourceExecVenue: Same as executionVenue of aggregated order (e.g., XHKG)

  4. Internalized Trades (Different Execution Capacities)

    • Test Case 1: An order is partially filled by internal cross with another agency client, and partially filled from the In-Scope Broker's own inventory.
      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XA (for the part filled by internal cross) / XP (for the part filled from the In-Scope Broker's inventory)

  5. Odd Lot or Special Lot Trades (Internalized)

    • Test Case: An odd lot or special lot trade is provided as an internalized trade by an In-Scope Broker.
      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XP
      • executionVenue: XOFF14
      • oddLotTrade: true
      • orderCapacity: A

  6. Odd Lot or Special Lot Trades (Exchange)

    • Test Case: An odd lot or special lot trade is filled via an exchange facility directly.
      • crossTrade: false
      • executionCapacity: A
      • executionVenue: XHKG
      • oddLotTrade: true

  7. Execution Correction

    • Test Case: An execution correction event is generated for a parent order with multiple child order splits and executions.
      • Corrected execution details (price and/or quantity)
      • Only one Execution Correction event per parent order
      • No additional Execution event after Execution Correction event

  8. Allocation

    • Test Case: An allocation event is generated after all Execution events of an aggregated order, with direct linkage to the client orders' LOID.
      • allocToLOID: LOID of client order
      • allocQty: Allocated quantity
      • One Allocation event per client order allocation

  9. Order Summary

    • Test Case 1: An Order Summary event is generated for a single-day parent order.

      • One Order Summary event per completed parent order
      • totalExecutedQty and avgExecutedPrice based on final settled quantity and price

    • Test Case 2: An Order Summary event is generated for a multi-day parent order.

      • One Order Summary event per end-of-day during order life-cycle
      • totalExecutedQty and avgExecutedPrice based on final settled quantity and price
      • orderCapacity: AP (if client order is intended to trade partially in agency capacity and partially in principal capacity)

Note that these test cases are not exhaustive and may need to be adjusted or expanded based on your specific implementation and requirements.

SelwynChan commented 1 year ago

Here are additional test cases based on the information provided. These test cases cover different scenarios not mentioned in the previous response.

  1. Internalized Trades (Agency Cross with different venues)

    • Test Case: Two orders are executed by crossing orders between agency clients through an ALP, each with a different execution venue.
      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XA
      • counterpartyID: Actual counterparty ID
      • executionVenue: Different for each order (e.g., XHKG, XDUB)

  2. Internalized Trades (Manual fills with different venues)

    • Test Case: Two orders are executed by manual fills, each with a different execution venue.
      • internalisedTrade: true
      • crossTrade: false
      • executionCapacity: A
      • executionVenue: Different for each order (e.g., XHKG, XDUB)

  3. Internalized Trades (Filled by In-Scope Broker's Inventory with different tradeBookIDs)

    • Test Case: Two orders are filled by the In-Scope Broker's own inventory, each with a different internal book.
      • internalisedTrade: true
      • crossTrade: true
      • executionCapacity: XP
      • tradeBookID: Different for each order (e.g., internalBook1, internalBook2)

  4. Internalized Trades (Multiple Post-Execution Allocations to different venues)

    • Test Case: An aggregated order is allocated to the constituent client orders, each with a different execution venue.
      • internalisedTrade: true
      • sourceExecVenue: Different for each order (e.g., XHKG, XDUB)

  5. Execution Correction (Multiple corrections within the same day)

    • Test Case: Multiple execution corrections are performed within the same day for a parent order with multiple child order splits and executions.
      • Corrected execution details (price and/or quantity) for each correction
      • Only the final Execution Correction event of the day is presented in the DS-OL format

  6. Allocation (Partial fills)

    • Test Case: An aggregated order is partially filled, and the fills are allocated to the constituent client orders.
      • allocToLOID: LOID of client order
      • allocQty: Allocated quantity (partial fill)
      • Partially filled Execution events prior to Allocation events

  7. Order Summary (Rejected orders)

    • Test Case: An Order Summary event is generated for a rejected parent order.
      • One Order Summary event for rejected parent order
      • totalExecutedQty: 0
      • avgExecutedPrice: N/A

  8. Order Summary (Partially completed orders)

    • Test Case: An Order Summary event is generated for a partially completed single-day parent order.
      • One Order Summary event for partially completed parent order
      • totalExecutedQty: Partially executed quantity
      • avgExecutedPrice: Based on executed quantity and price

  9. Order Summary (Constituent client orders with different execution capacities)

    • Test Case: An Order Summary event is generated for constituent client orders, each with a different execution capacity.
      • One Order Summary event per completed constituent client order
      • orderCapacity: A (for agency capacity) / P (for principal capacity)
      • totalExecutedQty and avgExecutedPrice based on final settled quantity and price

These additional test cases can help further validate your implementation under different scenarios. Remember that these test cases may need to be adjusted or expanded based on your specific implementation and requirements.

SelwynChan commented 1 year ago

Here's a summary of all test cases organized by overall category:

  1. Internalized Trades

    • Agency cross between clients
    • Manual fills
    • Filled by In-Scope Broker's Inventory
    • Agency cross with different venues
    • Manual fills with different venues
    • Filled by In-Scope Broker's Inventory with different tradeBookIDs
    • Multiple Post-Execution Allocations to different venues

  2. External Trades

    • Executed at an external venue
    • Executed at an external venue with different execution capacities
    • Executed at multiple external venues
    • Executed at multiple external venues with different execution capacities

  3. Allocation and Deallocation

    • Allocation of aggregated order to constituent client orders
    • Deallocation of aggregated order from constituent client orders
    • Allocation of aggregated order with different execution capacities
    • Allocation of aggregated order with different execution venues
    • Partial fills

  4. Execution Correction

    • Single execution correction within the same day
    • Multiple execution corrections within the same day

  5. Order Summary

    • Completed single-day parent order
    • Completed multi-day parent order (with executions on different days)
    • Rejected orders
    • Partially completed orders
    • Constituent client orders with different execution capacities

These categories cover the test cases generated in previous responses. Note that depending on the specific implementation and requirements, additional test cases may be necessary or some existing test cases may need to be adjusted.

SelwynChan commented 1 year ago

Below is a Python script that parses the given text and generates a CSV table with the specified delimiter and columns:

import re
import csv

# Read the text file
with open('input.txt', 'r') as f:
    content = f.read()

# Define a pattern for parsing each test case
pattern = re.compile(r'Test Case (\d+):\nName: (.*?)\nObjective: (.*?)\nInput: (.*?)\nExpected Result: (.*?)\n', re.DOTALL)

# Find all matches in the content
matches = pattern.findall(content)

# Write the parsed data to a CSV file
with open('output.csv', 'w', newline='', encoding='utf-8') as f:
    writer = csv.writer(f, delimiter=chr(31))
    writer.writerow(['Test Case Number', 'Name', 'Objective', 'Input', 'Expected Result'])

    for match in matches:
        writer.writerow(match)

To use this script, save it as parse_text.py and place your input text in a file named input.txt in the same directory. Then, run the script using Python, and it will generate an output CSV file called output.csv in the same directory.

Make sure your input text file follows the format specified in your question, with each test case separated by a newline.

SelwynChan commented 1 year ago

I apologize for the confusion. It seems there might be an issue with the regular expression pattern or the text file format. Let's modify the script to handle different line endings and ensure we capture the test cases correctly.

import re
import csv

# Read the text file
with open('input.txt', 'r', encoding='utf-8') as f:
    content = f.read()

# Normalize line endings
content = content.replace('\r\n', '\n').replace('\r', '\n')

# Define a pattern for parsing each test case
pattern = re.compile(r'Test Case (\d+):\nName: (.*?)\nObjective: (.*?)\nInput: (.*?)\nExpected Result: (.*?)\n', re.DOTALL)

# Find all matches in the content
matches = pattern.findall(content)

# Write the parsed data to a CSV file
with open('output.csv', 'w', newline='', encoding='utf-8') as f:
    writer = csv.writer(f, delimiter=chr(31))
    writer.writerow(['Test Case Number', 'Name', 'Objective', 'Input', 'Expected Result'])

    for match in matches:
        writer.writerow(match)

Ensure that your input.txt file follows the format specified in your question and has the test cases separated by newlines. If you still have issues, please provide a sample of your input text, and I will help you adjust the script accordingly.