|
| 1 | +# Porting Ably LiveObjects JavaScript integration tests to Swift |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +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. |
| 6 | + |
| 7 | +I have already: |
| 8 | + |
| 9 | +- ported the ObjectsHelper class |
| 10 | +- chosen how to map the JavaScript tests' parameterised testing to Swift Testing |
| 11 | +- ported the objectSyncScenarios and applyOperationsScenarios (with the aid of an LLM) |
| 12 | + |
| 13 | +You can see all of this in @ObjectsIntegrationTests.swift. |
| 14 | + |
| 15 | +Your task is to port the writeAPIScenarios to Swift. Begin by creating a TODO list for the remaining tests, then work on this TODO list. |
| 16 | + |
| 17 | +## Specific requirements for these ported tests |
| 18 | + |
| 19 | +- If you see any tests of argument validation that do not seem applicable to the Swift API (e.g. passing a type that the Swift type system would not allow), you can omit these tests and leave a comment explaining that you have done so. |
| 20 | + |
| 21 | +## Detailed general requirements for the ported tests |
| 22 | + |
| 23 | +Take the following requirements into account when coming up with your plan. |
| 24 | + |
| 25 | +- When translating the JS code to Swift, follow the existing patterns established by objectSyncSequenceScenarios where possible. |
| 26 | + |
| 27 | +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. |
| 28 | + |
| 29 | +- 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. |
| 30 | +- 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. |
| 31 | +- Handle JavaScript calls to the expectInstanceOf function as follows: |
| 32 | + - 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. |
| 33 | +- 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). |
| 34 | +- 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")`. |
| 35 | +- 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. |
| 36 | +- 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`. |
| 37 | +- 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. |
| 38 | +- 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.` |
| 39 | +- Our ObjectsHelper doesn't take a helper argument. |
| 40 | +- 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. |
| 41 | +- We have no helper instance that's passed to each test; the methods that exist on `helper` are currently just static methods on `Helper`. |
| 42 | +- do not copy the calls to `helper.recordPrivateAPI`; they're not relevant in this codebase |
| 43 | +- 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) |
| 44 | +- 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 |
| 45 | +- 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 |
| 46 | +- 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 |
0 commit comments