{"id":64704,"date":"2024-08-30T04:31:41","date_gmt":"2024-08-29T23:01:41","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=64704"},"modified":"2024-09-04T15:15:21","modified_gmt":"2024-09-04T09:45:21","slug":"swifts-new-testing-framework","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/swifts-new-testing-framework\/","title":{"rendered":"Swift\u2019s New Testing Framework"},"content":{"rendered":"

WWDC 2024 unveiled a major improvement to XCTest, which is Swift’s Testing Framework<\/strong>. I found it really beneficial while working on this. So I decided to share it with all of you. Let’s begin.<\/p>\n

Introduction<\/strong><\/h2>\n

Swift Testing allows you to use the Swift programming language\u2019s powerful and expressive capabilities to write tests with greater confidence and less code. The library works smoothly with Swift Package Manager and Xcode\u2019s testing workflow, allowing for flexible test organization, customizable metadata, and scalable test execution<\/p>\n

XCTest Vs Swift\u00a0Testing<\/strong><\/h2>\n

Now it\u2019s time to figure out why we require the Swift Testing Framework when we already have the XCTest Framework. How does it vary from XCTest, and what are the advantages of utilizing it over XCTest?<\/p>\n

XCTest Framework<\/strong><\/h2>\n

XCTest is Apple\u2019s default testing framework for Swift and Objective-C. It is built into Xcode and offers full support for unit, performance, and UI testing. XCTest is widely used because of its smooth interaction with Xcode, making it the preferred choice for many Swift developers.<\/p>\n

Key Features<\/strong><\/h2>\n
    \n
  1. Integration with Xcode:<\/strong> XCTest is strongly linked with Xcode, allowing for the simple creation of tests, execution, and debugging.<\/li>\n
  2. Assertion Library:<\/strong> XCTest provides a variety of assertions to validate test scenarios. Which makes it simple to utilize.<\/li>\n
  3. Code Coverage:<\/strong> Supports code coverage analysis to discover untested code.<\/li>\n<\/ol>\n

    Example:<\/h3>\n
    \"XCTest

    XCTest Example<\/p><\/div>\n

    Swift Testing Framework<\/h2>\n

    Swift Testing Framework, also known as Swift Test, is a modern framework created exclusively for writing tests in Swift. It seeks to give a more Swift-like, expressive, and powerful method of writing tests than the existing XCTest framework.<\/p>\n

    Key Features<\/h2>\n
      \n
    1. DSL for Tests:<\/strong> Swift Testing Frameworks frequently employ a Domain-Specific Language (DSL) to make test creation more intuitive and readable. This can result in tests that appear more like normal language than code.<\/li>\n
    2. First-Class Swift Support:<\/strong> These frameworks, which are specifically created for Swift, take advantage of the language\u2019s characteristics like optional, generics, and type inference to deliver a smoother testing experience.<\/li>\n
    3. Mocking and Stubbing:<\/strong> Many modern Swift Testing Frameworks provide support for mocking and stubbing, making it easy to separate the code being tested.<\/li>\n
    4. Asynchronous Testing:<\/strong> Improved support for testing asynchronous code, which is increasingly crucial in modern Swift applications.<\/li>\n<\/ol>\n

      Benefits of Swift\u00a0Testing<\/h2>\n
        \n
      1. Early Bug Detection:<\/strong> Writing tests helps detect bugs and obstacles early in the development process, minimizing the cost and work required to repair them later.<\/li>\n
      2. Refactoring Confidence:<\/strong> Tests serve as a safety net while rewriting code, ensuring that modifications do not introduce new bugs.<\/li>\n
      3. Documentation:<\/strong> Tests serve as documentation, demonstrating how the code should react in different contexts.<\/li>\n
      4. Continuous Integration:<\/strong> Automated tests can be added to continuous integration (CI) pipelines, guaranteeing that code changes are tested automatically.<\/li>\n<\/ol>\n

        Add Swift\u00a0Testing<\/h2>\n

        Let\u2019s understand how to add Swift Testing to an Existing Project or a new one.<\/p>\n

        1. Adding In Existing Project:-<\/strong> To add a new target follow the steps.
        \nClick File -> New -> Target<\/strong><\/p>\n

        \"Adding

        Adding Target<\/p><\/div>\n

        2. Choose Target:-<\/strong> In the target popup search for unit testing and select it as shown in the image.<\/p>\n

        \"Unit

        Unit Testing Target<\/p><\/div>\n

        3. Target Name:-<\/strong> Now give the name to the target and under the testing system select Swift Testing and click on finish.<\/p>\n

        \"Give

        Give Name and Select Swift Testing<\/p><\/div>\n

        Now we have imported Test Target here and It\u2019s time to write our first swift Test case.<\/p>\n

        Building Block of Swift\u00a0Testing<\/h2>\n

        1. Add Test\u00a0Case:<\/strong><\/h2>\n
        \"First

        First Swift Example<\/p><\/div>\n

        As per the above example, We just need to import the Testing<\/strong> framework to start working with Swift Testing<\/strong>. To make any function Testable we just need to add the @Test<\/strong> attribute. After adding this attribute a diamond box was added in front to test the function.<\/p>\n

        2. Adding Expectation<\/strong><\/h2>\n

        After adding the Test case we have to put our expectations by using macros provided by the framework.<\/p>\n

        i. #expect:-<\/strong> By using this macro we can define our expectations. It\u2019s validated whether the given condition is true or false. We don\u2019t need to add multiple asserts to validate Bool conditions like XCAssertEqual, XCTAssertNotEqual, XCTAssertTrue, etc. Let\u2019s understand it by example.<\/p>\n

        \"#expect

        #expect macro uses<\/p><\/div>\n

        As we can see one success<\/strong> expectation and one failure<\/strong> expectation. Here we are Testing two cases one is equalTo and the other is greaterThan and both can be executed using #expect<\/strong> macro. While in XCTest<\/strong> we have two asserts in this case.<\/p>\n

        ii: #expect(.throws: (any Error).self):-<\/strong> This macro is used to expect an error to be thrown. You specify the error type or the actual error that you expect to be thrown. The test will fail if the code within the macro does not throw an error, or if the error is not what is intended. By using (any Error).self<\/strong>, you are indicating that the code should throw any error that confirms the Error protocol.<\/p>\n

        \"Example

        Example of #expect (.throws: (any Error).self).<\/span><\/p><\/div>\n

        iii. #require macro:-<\/strong> This macro is used, as its name suggests when a method needs to run certain prerequisites before continuing with the test case. If the necessary circumstances are not met, the test fails. Let us examine an example.<\/p>\n

        \"Example

        Example of #require macro<\/p><\/div>\n

        In the above example, we can see that if a name is nil #require<\/strong> macros get failed and stop the execution of #expect<\/strong> macro.<\/p>\n

        Swift\u2019s New Testing<\/strong> Framework has added a number of new macros. In upcoming articles, we shall talk more about that. Let us now go to another set of building blocks.<\/p>\n

        3. Traits<\/strong><\/h2>\n

        Traits are basically to used for defining the characteristics, attributes, or behaviors of a block of code or function. It is also used to define the descriptive information of test cases. Let\u2019s have a look at how to define a trait.<\/p>\n

        \"Example

        Example of Traits<\/p><\/div>\n

        As we can see in the above example when we define the traits for any test case method it replaces the name of the function with the given traits in the Left Navigation Pane. It is useful to define the cases and easy to find out and debug when it fails.<\/p>\n

        There are so many Traits that are introduced with Swift\u2019s New Testing<\/strong> Framework. You can check in this Link.<\/a><\/p>\n

        4. Test\u00a0Suites<\/strong><\/h2>\n

        Suites are basically used to combine the Test function<\/strong> and Suites<\/strong>. It can be annotated using @suite<\/strong>. Any Test function<\/strong> is implicitly considered a suite. Suites can have stored properties. It can have init<\/strong> and deInit<\/strong> methods for set-up<\/strong> and tear-down<\/strong> logic respectively. Whenever we create an object of any suite it automatically calls init()<\/strong> method and after Test cases run successfully it needs to be de-initialized like we were working on class and structs.\u00a0 Let\u2019s have a look at an example.<\/p>\n

        \"Example

        Example of Suite<\/p><\/div>\n

        As we can see in the above example, All the test cases regarding Name are combined in a single suite and we have given descriptive info about the suite that will display in the left navigation pan as in the image.<\/p>\n

        Parameterized testing<\/h1>\n

        Swift Testing framework allows us to pass parameters in a function that makes them testable with multiple different values. This makes tests more efficient and manageable. Let\u2019s look an example.<\/p>\n

        \"Example

        Example of Parameterized Test Case<\/p><\/div>\n

        We have created a test case that expects that the given email ID should not be nil. But at the same time, we got a compile time error which indicates that we have to pass the argument value within the @Test Attributes<\/strong>. Let\u2019s correct it and see how it works.<\/p>\n

        \"Example

        Example of a Test case with a parameter<\/p><\/div>\n

        As we can see in the given example, We are passing an array of strings<\/strong> and the Test function<\/strong> iterates each of them and validates them. It will display the result of each parameter whether that Passes<\/strong> or Fail<\/strong> and if fail then what will be the reason? We can also check the result in the Left Navigation Pan<\/strong>. We can re-execute only the failed argument.<\/p>\n

        Conditional Testing<\/strong><\/h2>\n

        While we are working big project that has several Test cases and is in maintenance mode, we get a task to change in existing behavior of the app. In this case, chances are very high to impact the test case. So We may be required to disable some test cases or only need to run in certain conditions. Here Swift Testing frameworks<\/strong> to help us to do this with minimal changes by using\u00a0.enable<\/strong> or\u00a0.disable<\/strong> attributes with @Test<\/strong>.<\/p>\n

        \"Example

        Example of\u00a0.enable attribute<\/p><\/div>\n

        \"Example

        Example of\u00a0.disable attribute<\/p><\/div>\n

        In the given example we have used .enable and .disable attributes. For using .enable attribute we need to pass a specific condition. If the condition is true it will execute else it will skip the test. Same with the disable attribute. If we add this attribute, the test case will skipped and show the description.<\/p>\n

        Conclusion<\/h2>\n

        Test behaviors can be declared with less code thanks to Swift Testing\u2019s expressive API with macros. Swift expressions and operators are used by the #expect API to validate the supplied expressions. Moreover, Swift Testing facilitates parallel testing, which raises the general productivity and efficiency of testing.<\/p>\n","protected":false},"excerpt":{"rendered":"

        WWDC 2024 unveiled a major improvement to XCTest, which is Swift’s Testing Framework. I found it really beneficial while working on this. So I decided to share it with all of you. Let’s begin. Introduction Swift Testing allows you to use the Swift programming language\u2019s powerful and expressive capabilities to write tests with greater confidence […]<\/p>\n","protected":false},"author":1759,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":70},"categories":[1400],"tags":[6378],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64704"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1759"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=64704"}],"version-history":[{"count":5,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64704\/revisions"}],"predecessor-version":[{"id":65170,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/64704\/revisions\/65170"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=64704"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=64704"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=64704"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}