Add 2 posts about Swift Testing from this week

content/posts/series/swift-testing-vs-xctest/4-disable-tests/index.md

@@ -0,0 +1,48 @@
+---
+title: '#4 XCTest vs. Swift Testing - Disable tests - handle with care'
+date: 2024-11-27
+tags: ['Swift', 'XCTest', 'Swift Testing', 'unit testing', 'Testing']
+series: "XCTest vs. Swift Testing"
+cover: 
+  image: 'images/cover.png'
+  alt: '#4 XCTest vs. Swift Testing - Disable tests - handle with care'
+---
+
+This week with Swift Testing starts with checking how test disabling differs from XCTest.
+
+In XCTest, Xcode identifies a function as a test only if its name starts with the "test" prefix, so putting e.g. "disabled" instead makes the test inactive.
+Swift Testing simplifies that approach by introducing the @Test macro with a `.disabled` trait that you can pass as an argument.
+
+What’s the benefit? 
+You no longer need to modify each test name to disable it. What’s more, you can include context directly within the trait to justify why the test is disabled.
+
+Do I like it? You bet! I’m really glad that Xcode no longer depends on a "test" or other prefix 🥳
+
+Na matter what’s the motive, your goal should always be to resolve it, because a disabled test does not provide any value to the project.
+
+![Example](images/example.gif)
+
+Code ⤵️
+
+XCTest
+```swift
+// Disabled due to bug #12345
+func disabled_testExampleTest() {
+    XCTAssertEqual(1 + 1, 3)
+}
+```
+
+Swift Testing
+```swift
+@Test(.disabled("Disabled due to bug #12345"))
+func exampleTest() {
+    #expect(1 + 1 == 3)
+}
+```
+
+Why is "handle with care" mentioned in the title?
+It’s simple - disabling a test it’s a rare situation and must always come with a good reason.
+- Randomly failing test blocks a team from progressing - valid reason.
+- Changes in the production code without updating tests - that should never happen.
+
+{{< footer >}}

content/posts/series/swift-testing-vs-xctest/5-conditional-disabling/index.md

@@ -0,0 +1,50 @@
+---
+title: '#5 XCTest vs. Swift Testing - Conditional disabling - when a test needs a nap'
+date: 2024-11-28
+tags: ['Swift', 'XCTest', 'Swift Testing', 'unit testing', 'Testing']
+series: "XCTest vs. Swift Testing"
+cover: 
+  image: 'images/cover.png'
+  alt: '#5 XCTest vs. Swift Testing - Conditional disabling - when a test needs a nap'
+---
+
+Today we check the diff in conditional disabling.
+
+- In XCTest there is `XCTSkipIf` function that takes `Bool` argument to decide whether a test should run or not.
+- In Swift Testing there’s "disable" trait accepting `Bool` argument and behaving like `XCTSkipIf` from XCTest.
+
+XCTSkipIf - are you surprised this kind of function exists? To be honest - I was
+
+I can admit I learned about it when preparing this post. This already shows how often I’ll be using the Swift Testing version of it, but never say never!
+
+Anyway, Swift Testing lets you move the disabling logic outside of the test body, giving it a cleaner, more intuitive syntax. For me, that’s a win over XCTest.
+
+![Example](images/example.gif)
+
+Code ⤵️
+
+XCTest
+```swift
+enum FeatureFlag {
+    static let isExampleTestDisabled = true
+}
+
+func testExampleTest() throws {
+    try XCTSkipIf(FeatureFlag.isExampleTestDisabled)
+    XCTAssertEqual(1 + 1, 3)
+}
+```
+
+Swift Testing
+```swift
+enum FeatureFlag {
+    static let isExampleTestDisabled = true
+}
+
+@Test(.disabled(if: FeatureFlag.isExampleTestDisabled))
+func exampleTest() throws {
+    #expect(1 + 1 == 3)
+}
+```
+
+{{< footer >}}