Prompts, Repomix, TODO.md for porting integration tests

These were used to generate the contents of #57. Try and turn some of
this into some useful process in #60.

Most of the prompt- files were based on top of each other, i.e. small
modifications to the previous one, there might be a useful template
here.

Author: lawrence-forooghian

Attempting to write a prompt for writing a plan for remaining integration tests.md

@@ -0,0 +1,42 @@
+# Porting Ably LiveObjects JavaScript integration tests to Swift
+
+## Overview
+
+Take a look at the attached Repomix output. This belongs to a codebase called ably-js, which offers the same LiveObjects functionality as this Swift plugin. The file objects.test.js offers various integration tests for the LiveObjects functionality. I wish to port these tests to Swift.
+
+I have already:
+
+- ported the ObjectsHelper class
+- chosen how to map the JavaScript tests' parameterised testing to Swift Testing
+- ported the objectSyncScenarios (with the aid of an LLM)
+
+You can see all of this in the attached ObjectsIntegrationTests.swift.
+
+Ultrathink and create a step-by-step plan for how to use an LLM to port the remaining tests to Swift.
+
+## Detailed requirements for the ported tests
+
+Take the following requirements into account when coming up with your plan.
+
+- When translating the JS code to Swift, follow the existing patterns established by objectSyncSequenceScenarios where possible.
+
+Also consider the following requirements, which I supplied to the LLM when it ported the objectSyncScenarios. Some of these requirements are likely already represented in the tests that have been ported so far.
+
+- Do not omit any actions or assertions from the JavaScript implementation except when explicitly instructed to do so. If you are not able to convert part of the JavaScript implementation, leave a TODO comment explaining what needs to be done.
+- If the JavaScript tests assume that an object is non-null but this is not something that the Swift compiler inherently knows, favour using Swift Testing's #require macro instead of force unwrapping.
+- Handle JavaScript calls to the expectInstanceOf function as follows:
+  - If it is a check that we don't need because it's guaranteed by the Swift type system, then don't copy this call; instead just add a comment in its place explaining why it's been omitted.
+- If it is a check that a LiveMap contains an entry of a particular type, then keep the check but instead of checking the type of the value, check that it has the correct case in the LiveMapValue enum (you can use the liveCounterValue etc convenience getters for this).
+- When converting a simple inline assertion about the contents of a LiveMap, convert by following this example: `expect(valuesMap.get('stringKey')).to.equal('stringValue', 'Check values map has correct string value key')` should become `#expect(try #require(valuesMap.get(key: "stringKey")?.stringValue) == "stringValue", "Check values map has correct string value key")`.
+- In one place, the JavaScript tests call channel.client; this property does not exist in the Swift equivalent so instead create a local variable called let client = context.client at the top of the method and use this.
+- When the JavaScript tests use a local variable that is a `Promise` which will be awaited later (usually the naming will indicate this; e.g. `counterCreatedPromise`), represent this in Swift as an `async let` variable of the same name, e.g. `async let counterCreatedPromise`.
+- When the JavaScript tests use a local variable that is a fixed-size array of `Promise`s that will be awaited later, then use an `async let` local array variable of the same name.
+- When the JavaScript tests use a local variable that is a variable-size array of `Promise`s that will be awaited later, then use an `async let` variable that is backed by a `TaskGroup.`
+- Our ObjectsHelper doesn't take a helper argument.
+- We converted ably-js's `channel.attach()` into a call to our internal helper `channel.attachAsync()` which uses Swift Concurrency; we may need these for other methods too. You can add these helper methods in the Ably+Concurrency.swift file.
+- We have no helper instance that's passed to each test; the methods that exist on `helper` are currently just static methods on `Helper`.
+- do not copy the calls to `helper.recordPrivateAPI`; they're not relevant in this codebase
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that is easy to implement as a test helper, do so (e.g. Base64 decoding, or comparison of binary data)
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that seem to genuinely require the LiveObjects SDK to provide a special test hook, add a stub helper method for doing this which calls `fatalError()`, with a TODO in it
+- If you need to add any of the top-level helper functions from the JavaScript file, then add them as top-level functions in the Swift test file
+- The aim is to get the tests to compile; they are not yet expected to pass and you do not need to run the tests

TODO.md

@@ -0,0 +1,9 @@
+- [ ] it has missed out some of the primitiveKeyData (e.g. max integer)
+- [x] the primitiveKeyData need DRYing up — and I need to understand what types they should be
+- [ ] some of the code that checks unsubscribe might be a bit racy — e.g. it might just be that you didn't see an update yet because you dispatched its handling into a `Task`
+- [ ] there are a bunch of `if case` statements in the tests which make me worry that some tests might end up being no-ops
+- [x] processDeserializedProtocolMessage should really be using the internal queue
+- [ ] bring in line with latest tests
+- [ ] make it know that when injecting a sequence of object operation messages, it matters that it be done sequentially else some operations will be skipped due to serial being less than last applied
+- [ ] why are the integration tests either failing (fatalError due to an assertion without a test being in progress, or just hanging) when logging is enabled?
+- [ ] consistently use one tool for handling synchronous subscriptions in integration tests (`Subscriber`? because that supports unsubscribe too) and then use that everywhere, and document it

prompt-DRY-up-fixtures.md

@@ -0,0 +1,17 @@
+# Porting Ably LiveObjects JavaScript integration tests to Swift
+
+## Overview
+
+Take a look at the attached Repomix output. This belongs to a codebase called ably-js, which offers the same LiveObjects functionality as this Swift plugin. The file objects.test.js offers various integration tests for the LiveObjects functionality. I wish to port these tests to Swift.
+
+I have already:
+
+- ported the ObjectsHelper class
+- chosen how to map the JavaScript tests' parameterised testing to Swift Testing
+- ported the objectSyncScenarios, applyOperationsScenarios, writeAPIScenarios, subscriptionCallbacksScenarios, and applyOperationsDuringSyncScenarios (with the aid of an LLM)
+
+You can see all of this in @ObjectsIntegrationTests.swift.
+
+The LLM that ported the tests did not do a good job of porting the fixtures. Instead of porting the top level fixtures, it has created individual local variable fixtures in each of the tests. I wish for you to rectify this mistake and DRY up these fixtures. I want you to create top level variables for primitiveKeyData, primitiveMapsFixtures, and countersFixtures, and update the tests to use these.
+
+In the case where the local variable in a test currently has some additional fields, such as the swiftValue or the restData, I want you to include this value in the top level fixtures, such that the top level data is the union of all the fields in the current local variables. And I want there to be a comment explaining exactly why this additional field exists.

prompt-applyOperationsDuringSyncScenarios.md

@@ -0,0 +1,42 @@
+# Porting Ably LiveObjects JavaScript integration tests to Swift
+
+## Overview
+
+Take a look at the attached Repomix output. This belongs to a codebase called ably-js, which offers the same LiveObjects functionality as this Swift plugin. The file objects.test.js offers various integration tests for the LiveObjects functionality. I wish to port these tests to Swift.
+
+I have already:
+
+- ported the ObjectsHelper class
+- chosen how to map the JavaScript tests' parameterised testing to Swift Testing
+- ported the objectSyncScenarios, applyOperationsScenarios, writeAPIScenarios, and subscriptionCallbacksScenarios (with the aid of an LLM)
+
+You can see all of this in @ObjectsIntegrationTests.swift.
+
+Your task is to port the applyOperationsDuringSyncScenarios to Swift. Begin by creating a TODO list for the remaining tests, then work on this TODO list.
+
+## Detailed general requirements for the ported tests
+
+Take the following requirements into account when coming up with your plan.
+
+- When translating the JS code to Swift, follow the existing patterns established by the already-ported tests where possible.
+
+Also consider the following requirements, which I supplied to the LLM when it ported the objectSyncScenarios. Some of these requirements are likely already represented in the tests that have been ported so far.
+
+- Do not omit any actions or assertions from the JavaScript implementation except when explicitly instructed to do so. If you are not able to convert part of the JavaScript implementation, leave a TODO comment explaining what needs to be done.
+- If the JavaScript tests assume that an object is non-null but this is not something that the Swift compiler inherently knows, favour using Swift Testing's #require macro instead of force unwrapping.
+- Handle JavaScript calls to the expectInstanceOf function as follows:
+  - If it is a check that we don't need because it's guaranteed by the Swift type system, then don't copy this call; instead just add a comment in its place explaining why it's been omitted.
+- If it is a check that a LiveMap contains an entry of a particular type, then keep the check but instead of checking the type of the value, check that it has the correct case in the LiveMapValue enum (you can use the liveCounterValue etc convenience getters for this).
+- When converting a simple inline assertion about the contents of a LiveMap, convert by following this example: `expect(valuesMap.get('stringKey')).to.equal('stringValue', 'Check values map has correct string value key')` should become `#expect(try #require(valuesMap.get(key: "stringKey")?.stringValue) == "stringValue", "Check values map has correct string value key")`.
+- In one place, the JavaScript tests call channel.client; this property does not exist in the Swift equivalent so instead create a local variable called let client = context.client at the top of the method and use this.
+- When the JavaScript tests use a local variable that is a `Promise` which will be awaited later (usually the naming will indicate this; e.g. `counterCreatedPromise`), represent this in Swift as an `async let` variable of the same name, e.g. `async let counterCreatedPromise`.
+- When the JavaScript tests use a local variable that is a fixed-size array of `Promise`s that will be awaited later, then use an `async let` local array variable of the same name.
+- When the JavaScript tests use a local variable that is a variable-size array of `Promise`s that will be awaited later, then use an `async let` variable that is backed by a `TaskGroup.`
+- Our ObjectsHelper doesn't take a helper argument.
+- We converted ably-js's `channel.attach()` into a call to our internal helper `channel.attachAsync()` which uses Swift Concurrency; we may need these for other methods too. You can add these helper methods in the Ably+Concurrency.swift file.
+- We have no helper instance that's passed to each test; the methods that exist on `helper` are currently just static methods on `Helper`.
+- do not copy the calls to `helper.recordPrivateAPI`; they're not relevant in this codebase
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that is easy to implement as a test helper, do so (e.g. Base64 decoding, or comparison of binary data)
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that seem to genuinely require the LiveObjects SDK to provide a special test hook, add a stub helper method for doing this which calls `fatalError()`, with a TODO in it
+- If you need to add any of the top-level helper functions from the JavaScript file, then add them as top-level functions in the Swift test file
+- The aim is to get the tests to compile; they are not yet expected to pass and you do not need to run the tests

prompt-applyOperationsScenarios.md

@@ -0,0 +1,42 @@
+# Porting Ably LiveObjects JavaScript integration tests to Swift
+
+## Overview
+
+Take a look at the attached Repomix output. This belongs to a codebase called ably-js, which offers the same LiveObjects functionality as this Swift plugin. The file objects.test.js offers various integration tests for the LiveObjects functionality. I wish to port these tests to Swift.
+
+I have already:
+
+- ported the ObjectsHelper class
+- chosen how to map the JavaScript tests' parameterised testing to Swift Testing
+- ported the objectSyncScenarios (with the aid of an LLM)
+
+You can see all of this in @ObjectsIntegrationTests.swift.
+
+Your task is to port the applyOperationsScenarios to Swift.
+
+## Detailed requirements for the ported tests
+
+Take the following requirements into account when coming up with your plan.
+
+- When translating the JS code to Swift, follow the existing patterns established by objectSyncSequenceScenarios where possible.
+
+Also consider the following requirements, which I supplied to the LLM when it ported the objectSyncScenarios. Some of these requirements are likely already represented in the tests that have been ported so far.
+
+- Do not omit any actions or assertions from the JavaScript implementation except when explicitly instructed to do so. If you are not able to convert part of the JavaScript implementation, leave a TODO comment explaining what needs to be done.
+- If the JavaScript tests assume that an object is non-null but this is not something that the Swift compiler inherently knows, favour using Swift Testing's #require macro instead of force unwrapping.
+- Handle JavaScript calls to the expectInstanceOf function as follows:
+  - If it is a check that we don't need because it's guaranteed by the Swift type system, then don't copy this call; instead just add a comment in its place explaining why it's been omitted.
+- If it is a check that a LiveMap contains an entry of a particular type, then keep the check but instead of checking the type of the value, check that it has the correct case in the LiveMapValue enum (you can use the liveCounterValue etc convenience getters for this).
+- When converting a simple inline assertion about the contents of a LiveMap, convert by following this example: `expect(valuesMap.get('stringKey')).to.equal('stringValue', 'Check values map has correct string value key')` should become `#expect(try #require(valuesMap.get(key: "stringKey")?.stringValue) == "stringValue", "Check values map has correct string value key")`.
+- In one place, the JavaScript tests call channel.client; this property does not exist in the Swift equivalent so instead create a local variable called let client = context.client at the top of the method and use this.
+- When the JavaScript tests use a local variable that is a `Promise` which will be awaited later (usually the naming will indicate this; e.g. `counterCreatedPromise`), represent this in Swift as an `async let` variable of the same name, e.g. `async let counterCreatedPromise`.
+- When the JavaScript tests use a local variable that is a fixed-size array of `Promise`s that will be awaited later, then use an `async let` local array variable of the same name.
+- When the JavaScript tests use a local variable that is a variable-size array of `Promise`s that will be awaited later, then use an `async let` variable that is backed by a `TaskGroup.`
+- Our ObjectsHelper doesn't take a helper argument.
+- We converted ably-js's `channel.attach()` into a call to our internal helper `channel.attachAsync()` which uses Swift Concurrency; we may need these for other methods too. You can add these helper methods in the Ably+Concurrency.swift file.
+- We have no helper instance that's passed to each test; the methods that exist on `helper` are currently just static methods on `Helper`.
+- do not copy the calls to `helper.recordPrivateAPI`; they're not relevant in this codebase
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that is easy to implement as a test helper, do so (e.g. Base64 decoding, or comparison of binary data)
+- when the calls to `helper.recordPrivateAPI` refer to a piece of functionality that seem to genuinely require the LiveObjects SDK to provide a special test hook, add a stub helper method for doing this which calls `fatalError()`, with a TODO in it
+- If you need to add any of the top-level helper functions from the JavaScript file, then add them as top-level functions in the Swift test file
+- The aim is to get the tests to compile; they are not yet expected to pass and you do not need to run the tests