#swifttesting — Public Fediverse posts

#buildInPublic #CoreData #swiftTesting

To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.

back to regularly scheduled programming…

18/n

#buildInPublic #CoreData #swiftTesting

To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.

back to regularly scheduled programming…

18/n

#buildInPublic #CoreData #swiftTesting

To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.

back to regularly scheduled programming…

18/n

#buildInPublic #CoreData #swiftTesting

Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSet

Unfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n

#buildInPublic #CoreData #swiftTesting

Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSet

Unfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n

#buildInPublic #CoreData #swiftTesting

Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSet

Unfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n

#buildInPublic #CoreData #swiftTesting

bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n

#buildInPublic #CoreData #swiftTesting

bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n

#buildInPublic #CoreData #swiftTesting

bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n

#buildInPublic #CoreData #swiftTesting

lets do the simplest case first: AbcTune to TDMTune.

15/n

#buildInPublic #CoreData #swiftTesting

lets do the simplest case first: AbcTune to TDMTune.

15/n

#buildInPublic #CoreData #swiftTesting

lets do the simplest case first: AbcTune to TDMTune.

15/n

#buildInPublic #CoreData #swiftTesting

next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.

As part of that I'll need to look at how to de-duplicate with respect to existing objects.

14/n

#buildInPublic #CoreData #swiftTesting

next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.

As part of that I'll need to look at how to de-duplicate with respect to existing objects.

14/n

#buildInPublic #CoreData #swiftTesting

next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.

As part of that I'll need to look at how to de-duplicate with respect to existing objects.

14/n

#buildInPublic #CoreData #swiftTesting

ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.

(edit to put the GitHub link in)

https://github.com/Wil-Macaulay/attributedRelationships

13/n

#buildInPublic #CoreData #swiftTesting

ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.

(edit to put the GitHub link in)

https://github.com/Wil-Macaulay/attributedRelationships

13/n

#buildInPublic #CoreData #swiftTesting

ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.

(edit to put the GitHub link in)

https://github.com/Wil-Macaulay/attributedRelationships

13/n

#buildInPublic #CoreData #swiftTesting

I found a few similar ways of doing this using enum with associated type

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift

This one from @paulio87 seems the most straightforward to me:

https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/

it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.

(12/n)

#buildInPublic #CoreData #swiftTesting

I found a few similar ways of doing this using enum with associated type

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift

This one from @paulio87 seems the most straightforward to me:

https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/

it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.

(12/n)

#buildInPublic #CoreData #swiftTesting

I found a few similar ways of doing this using enum with associated type

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift

This one from @paulio87 seems the most straightforward to me:

https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/

it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.

(12/n)

#buildInPublic #CoreData #swiftTesting

(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)

I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)

#buildInPublic #CoreData #swiftTesting

(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)

I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)

#buildInPublic #CoreData #swiftTesting

(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)

I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)

Writing Swift Testing tests with AI should still result in deterministic tests.

My Swift Testing Expert Agent Skill helps agents avoid unnecessary @MainActor and .serialized, and use parameterized tests when they fit:

https://www.avanderlee.com/ai-development/swift-testing-agent-skill-write-high-quality-tests-with-ai/?utm_source=mastodon&utm_medium=social&utm_campaign=swiftlee_social_evergreen&utm_content=swiftlee-20260712T1723-skill_promo-001_x

#swiftlang #swifttesting

Writing Swift Testing tests with AI should still result in deterministic tests.

My Swift Testing Expert Agent Skill helps agents avoid unnecessary @MainActor and .serialized, and use parameterized tests when they fit:

https://www.avanderlee.com/ai-development/swift-testing-agent-skill-write-high-quality-tests-with-ai/?utm_source=mastodon&utm_medium=social&utm_campaign=swiftlee_social_evergreen&utm_content=swiftlee-20260712T1723-skill_promo-001_x

#swiftlang #swifttesting

Writing Swift Testing tests with AI should still result in deterministic tests.

My Swift Testing Expert Agent Skill helps agents avoid unnecessary @MainActor and .serialized, and use parameterized tests when they fit:

https://www.avanderlee.com/ai-development/swift-testing-agent-skill-write-high-quality-tests-with-ai/?utm_source=mastodon&utm_medium=social&utm_campaign=swiftlee_social_evergreen&utm_content=swiftlee-20260712T1723-skill_promo-001_x

#swiftlang #swifttesting

Writing Swift Testing tests with AI should still result in deterministic tests.

My Swift Testing Expert Agent Skill helps agents avoid unnecessary @MainActor and .serialized, and use parameterized tests when they fit:

https://www.avanderlee.com/ai-development/swift-testing-agent-skill-write-high-quality-tests-with-ai/?utm_source=mastodon&utm_medium=social&utm_campaign=swiftlee_social_evergreen&utm_content=swiftlee-20260712T1723-skill_promo-001_x

#swiftlang #swifttesting

#buildInPublic #CoreData #swiftTesting

I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.

so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.

Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets

(10/n)

#buildInPublic #CoreData #swiftTesting

I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.

so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.

Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets

(10/n)

#buildInPublic #CoreData #swiftTesting

I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.

so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.

Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets

(10/n)

SourceLocation: The Secret to Better Custom Assertions in Swift Testing https://qualitycoding.org/swift-testing-custom-assertions/ #SwiftTesting

SourceLocation: The Secret to Better Custom Assertions in Swift Testing https://qualitycoding.org/swift-testing-custom-assertions/ #SwiftTesting

SourceLocation: The Secret to Better Custom Assertions in Swift Testing https://qualitycoding.org/swift-testing-custom-assertions/ #SwiftTesting

SourceLocation: The Secret to Better Custom Assertions in Swift Testing https://qualitycoding.org/swift-testing-custom-assertions/ #SwiftTesting

SourceLocation: The Secret to Better Custom Assertions in Swift Testing https://qualitycoding.org/swift-testing-custom-assertions/ #SwiftTesting

#buildInPublic #CoreData #swiftTesting

Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…

(9/n)

#buildInPublic #CoreData #swiftTesting

Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…

(9/n)

#buildInPublic #CoreData #swiftTesting

Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…

(9/n)

#buildInPublic #CoreData #swiftTesting

Do I need an explicit ‘type' field as shown here? let's see…

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

(8/n)

#buildInPublic #CoreData #swiftTesting

Do I need an explicit ‘type' field as shown here? let's see…

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

(8/n)

#buildInPublic #CoreData #swiftTesting

Do I need an explicit ‘type' field as shown here? let's see…

https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a

(8/n)

#buildInPublic #CoreData #swiftTesting

A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n)

#buildInPublic #CoreData #swiftTesting

A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n)

#buildInPublic #CoreData #swiftTesting

A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n)

#buildInPublic #CoreData #swiftTesting

incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb

(6/n)

#buildInPublic #CoreData #swiftTesting

incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb

(6/n)

#buildInPublic #CoreData #swiftTesting

incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb

(6/n)

#buildInPublic #CoreData #swiftTesting

Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n)

#buildInPublic #CoreData #swiftTesting

Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n)

#buildInPublic #CoreData #swiftTesting

Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n)

#buildInPublic #CoreData #swiftTesting

So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.

How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n)

#buildInPublic #CoreData #swiftTesting

So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.

How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n)

#buildInPublic #CoreData #swiftTesting

So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.

How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n)

#buildInPublic #CoreData #swiftTesting

types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.

There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)

#buildInPublic #CoreData #swiftTesting

types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.

There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)

#buildInPublic #CoreData #swiftTesting

types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.

There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)

#buildInPublic #CoreData #swiftTesting

Spending a little time figuring out the best way to build input files of test data. In the Objc days I used to read json into NSDictionaries and then build my domain objects from there. Swift has the Codable protocol (Encodable + Decodable) plus JSONEncoder / JSONDecoder which gives us a nice way of getting from json to domain objects. (2/n)

#buildInPublic #CoreData #swiftTesting

Spending a little time figuring out the best way to build input files of test data. In the Objc days I used to read json into NSDictionaries and then build my domain objects from there. Swift has the Codable protocol (Encodable + Decodable) plus JSONEncoder / JSONDecoder which gives us a nice way of getting from json to domain objects. (2/n)

#buildInPublic #CoreData #swiftTesting

Spending a little time figuring out the best way to build input files of test data. In the Objc days I used to read json into NSDictionaries and then build my domain objects from there. Swift has the Codable protocol (Encodable + Decodable) plus JSONEncoder / JSONDecoder which gives us a nice way of getting from json to domain objects. (2/n)