SwiftUI、SwiftData の公式チュートリアルってすごく良いですね
参考にしながら、まずは、Todo リスト的なものを作ってみました。
Landmarks というサンプルコードのタブに追加してみました。
Android の「Jetpack Compose + ストレージ的な何か」で作るより、簡単に直感的に作れるような気がしています。
もっと上手にプログラミングできるよう日々精進していこうと思います。
SwiftUI、SwiftData の公式チュートリアルってすごく良いですね
参考にしながら、まずは、Todo リスト的なものを作ってみました。
Landmarks というサンプルコードのタブに追加してみました。
Android の「Jetpack Compose + ストレージ的な何か」で作るより、簡単に直感的に作れるような気がしています。
もっと上手にプログラミングできるよう日々精進していこうと思います。
Xcode の Preview がクラッシュしっぱなし。
ストレージまわりの話ではないかと思いながらしらべる。
xcrun simctl -—set previews delete all
👉 Preview keeps crashing | Apple Developer Forums
👉 SwiftUIのプレビューが動かなくなった時の対処方法 #SwiftUI - Qiita
まずは、見てみますか。
#!/bin/bash
cd ~/Library/Logs/DiagnosticReports
file=$(ls XCPreview* | head -1)
open $file
何か起こったらログ確認大事。
いろいろありそうです。
このシミュレータですが、通常のシミュレータとは別でXcodeが持っています。しかしストレージ管理のデベロッパ欄には表示されない上に自動で削除されません。私の環境ではiOS14.1のシミュレータなども残っていました。
👉 【SwiftUI】PreviewのSimulator残留 | thwork
cd ~/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/
find . -name com.apple.suggestions.plist -exec plutil -replace SuggestionsAppLibraryEnabled -bool NO {} ";"
👉 [Tips]Xcode13.1のSwiftUIのpreviewでCPU使用率が高くなるのをSpotlightを止めて回避する(iOS15) #iOS - Qiita
- Restart the computer and re-run xcrun simctl --set previews delete all
- Delete stored Preview data directly. This data is stored in ~/Library/Developer/Xcode/UserData/Previews.
👉 Use Realm with SwiftUI Previews — Realm
xcrun simctl --set previews delete unavailable | all
👉 SwiftUI Previews - Disk space issue | Apple Developer Forums
Save space by
1. xcrun simctl delete unavailable
2. xcrun simctl erase all
3. Delete /Users/username/Library/Developer/CoreSimulator folder.
👉 swiftui - Xcode 13 UI Previews folder takes too much space - Stack Overflow
コマンドラインツールから help を確認する。
❯ xcrun simctl help
usage: simctl [--set <path>] [--profiles <path>] <subcommand> ...
simctl help [subcommand]
Command line utility to control the Simulator
For subcommands that require a <device> argument, you may specify a device UDID
or the special "booted" string which will cause simctl to pick a booted device.
If multiple devices are booted when the "booted" device is selected, simctl
will choose one of them.
Subcommands:
addmedia Add photos, live photos, videos, or contacts to the library of a device.
boot Boot a device or device pair.
clone Clone an existing device.
create Create a new device.
delete Delete specified devices, unavailable devices, or all devices.
diagnose Collect diagnostic information and logs.
erase Erase a device's contents and settings.
get_app_container Print the path of the installed app's container
getenv Print an environment variable from a running device.
help Prints the usage for a given subcommand.
icloud_sync Trigger iCloud sync on a device.
install Install an app on a device.
install_app_data Install an xcappdata package to a device, replacing the current contents of the container.
io Set up a device IO operation.
keychain Manipulate a device's keychain
launch Launch an application by identifier on a device.
list List available devices, device types, runtimes, or device pairs.
location Control a device's simulated location
logverbose enable or disable verbose logging for a device
openurl Open a URL in a device.
pair Create a new watch and phone pair.
pair_activate Set a given pair as active.
pbcopy Copy standard input onto the device pasteboard.
pbpaste Print the contents of the device's pasteboard to standard output.
pbsync Sync the pasteboard content from one pasteboard to another.
privacy Grant, revoke, or reset privacy and permissions
push Send a simulated push notification
rename Rename a device.
runtime Perform operations on runtimes
shutdown Shutdown a device.
spawn Spawn a process by executing a given executable on a device.
status_bar Set or clear status bar overrides
terminate Terminate an application by identifier on a device.
ui Get or Set UI options
uninstall Uninstall an app from a device.
unpair Unpair a watch and phone pair.
upgrade Upgrade a device to a newer runtime.
❯ xcrun simctl help delete
Delete specified devices, unavailable devices, or all devices.
Usage: simctl delete <device> [... <device n>] | unavailable | all
Specifying unavailable will delete devices that are not supported by the current Xcode SDK.
❯ xcrun simctl list devices
== Devices ==
-- iOS 17.0 --
iPhone SE (3rd generation) (EE4D7500-5439-4D41-AD42-6028F649FA44) (Shutdown)
iPhone 15 (984F204F-2D4E-4E56-8EEE-D11C46EDD9C2) (Shutdown)
iPhone 15 Plus (C1349C55-57AC-4E47-9EF3-71A848E24A4E) (Shutdown)
iPhone 15 Pro (04DC04FF-87DB-4EB6-91D8-C8CB4CF10015) (Shutdown)
iPhone 15 Pro Max (5DC11544-4C3E-4852-8899-3D9E0844519B) (Shutdown)
iPad Air (5th generation) (906B44B3-B298-4CF1-A5FB-0B4D43277636) (Shutdown)
iPad (10th generation) (3804C1FA-6306-4CB7-98E0-D24CAFA70537) (Shutdown)
iPad mini (6th generation) (351ED4C6-2DF3-4F1F-A29A-6D44483D9A95) (Shutdown)
iPad Pro (11-inch) (4th generation) (96D48442-96AA-421A-BBA6-6F45EE8ECDBE) (Shutdown)
iPad Pro (12.9-inch) (6th generation) (0B527419-DE2A-4146-93C4-55540B624C5C) (Shutdown)
❯ xcrun simctl --set previews list devices
Using Previews Device Set: '/Users/mao/Library/Developer/Xcode/UserData/Previews/Simulator Devices'
== Devices ==
-- iOS 17.0 --
iPhone 15 Pro (676858D4-35E8-4841-91F4-17804B3E7565) (Shutdown)
覚えておくべきは、
Preview は、シュミレータ単独と別枠でシュミレータを使っている。
ということ。
Preview と シュミレーターに関連する問題は多そうです。
私の場合スッキリ対応した方法としては、以下を Xcode を一旦終了して実行。
xcrun simctl --set previews delete all
rm -rf ~/Library/Developer/Xcode/UserData/Previews
rm -rf ~/Library/Developer/CoreSimulator/Caches
👉 How to clear/reset SwiftUI Preview Caches?
Behavors に入れときますか、消した previews に関しては自動で作成されると思って良さそう。
職場や開発環境や対象となるサービスによっては、テストが「だるすぎ」と思えることがあります。
世界的に著名な方々の意見が気になりますよね。
どのように心得て書くべきか、というようなことをまとめてくれています。
「Mock」についてです。
👉 Unit Testing Experts on Mocks | Perry Street Software Engineering
In classic tests, many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors
When you write a mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers. A classic test only cares about the final state — not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.
I don’t see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation. I really like the fact that while writing the test you focus on the result of the behavior, not how it’s done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.
Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems. 1. The setup code can get extremely complicated. 2. The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.
The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded ‘design damage’.
I recommend that you mock sparingly. Find a way to test — design a way to test — your code so that it doesn’t require a mock.
I mock almost nothing. If I can’t figure out how to test efficiently with the real stuff, I find another way of creating a feedback loop for myself.
If I use TDD, I can refactor stuff. And then I heard these stories people say that they use TDD and now they can’t refactor anything. I couldn’t understand that and then I started looking at their tests: If you have mocks returning mocks, returning mocks, your test is completely coupled to the implementation, not the interface, but the exact implementation. Of course you can’t change anything without breaking the test. That for me is too high a price to pay, that’s not a trade-off I’m willing to make.
👉 TW Hangouts | Is TDD dead? - YouTube
When we refactored something all these tests with mocks broke and we had to rewrite all the mocks. It was kind of puzzling because the promise was that we should be able to refactor our code, because our tests would enable us to refactor and refactoring kept our code healthy. But the tests were an obstacle to that change, since they were breaking when we changed our implementation details.
Avoid heavy mocking. This allows you to meet the promise to refactoring. You will refactor your code and your tests won’t break.
Mocks are useful when a resource is expensive to create, but the problem with mock objects essentially is that people have used them to isolate classes. Don’t do that.
👉 🚀 TDD, Where Did It All Go Wrong (Ian Cooper) - YouTube
大まかにまとめると以下の3つ。
Mock はインタラクション(やり取り/相互作用)の確認が目的である。
リソース作成のコストが高い場合に便利。
実装と密になるので、実装は変更はしづらくなっていく。
ホンマもんのエンジニアの方々に口を揃えて言われるとスッキリします。