Hi,
I create a ModelContainer in test class.
final class NewNotPaidTrTest: XCTestCase {
@MainActor
let testContainer: ModelContainer = {
do {
let container = try ModelContainer (for: Category.self, Account.self, Transaction.self, configurations: ModelConfiguration(isStoredInMemoryOnly: true))
container.mainContext.insert(Category.preview)
container.mainContext.insert(Account.preview)
return container
} catch {
fatalError("Failed to create container")
}
}()
@MainActor func testNewNotPaidTr() throws {
let tr = Transaction(amount: 1000, date: Date.now, notes: "", isMovement: false, isPaid: false, planAuto: false)
debugPrint(Account.preview.name)
testContainer.mainContext.insert(tr)
tr.account = Account.preview
tr.category = Category.preview
Account.updateBalance(tr, isAddTr: true)
XCTAssertEqual(tr.account!.balance, 123400, "Fallita -> \(tr.account!.balance)")
do {
try testContainer.mainContext.save()
} catch {
fatalError("Failed to save")
}
testContainer.mainContext.delete(tr)
Account.updateBalance(tr, isAddTr: false)
XCTAssertEqual(tr.account!.balance, 123400, "Fallita -> \(tr.account!.balance)")
}
}
Post
Replies
Boosts
Views
Activity
Hi @Appeloper, I'm trying to manage my SwiftUI+SwiftData project using the MV approach described in the post. I would like to understand, following this approach, how to handle the case of a view used to edit the swift data object (e.g. Recipe in the previous post) in which it is necessary to perform some operations before actually confirming the saving and updating of the modified fields. Currently my solution is to pass the information into a support observabel class called, perhaps improperly, viewmodel in which there are all the data of the swiftdata object and the saving and removing functions. Is there a more consistent way with the model?
Hi @Chandan_ Why do we always say as a con that there is no "clear separation of concerns". The purpose of this requirement, for practical purposes, is it not enough that the code is correctly ordered, possibly also separating it into multiple files so that any commits from different developers do not touch each other? Is there anything else I don't see? ( @Chandan_ , I tag you, as the last one who wrote it, but equally many others)