commit | 341872b50ebda1d0dce378bbd636f70000fe70bb | [log] [tgz] |
---|---|---|
author | Daniel Rodríguez Troitiño <danielrodriguez@fb.com> | Mon Sep 30 15:03:35 2019 -0700 |
committer | Daniel Rodríguez Troitiño <danielrodriguez@fb.com> | Mon Sep 30 15:03:35 2019 -0700 |
tree | 2aa35f8fcd9f1f2176661fb9f28474f10e5f91de | |
parent | f62c026cb2f2f162bb3b3d93ae49969b60652e0b [diff] |
[test] Rewrite URLSession cookie tests to be independent. Some cookie tests were depending on previously run tests to be successful. Rewrite all the tests to be independent from each other. The first change is that all the tests that deal with cookies try to clean their cookie storages before starting the testing. This should avoid previous state leaking into the current test. Some other changes are made to clarify how the cookie tests are actually performed. To check that the cookies are set by URLSession, an special endpoint that echoes back the request header are used. To make it clear, that endpoint has changed names. In the cases that we were checking that the response headers were setting the cookies, we actually check for the right headers to been set, not some random data in the response (because for some reason, the request headers were also being echo in another endpoint, which might have created false positives). There is also some cleaning of unused variables and var that should have been let. I tested this by running all the tests in TestURLSession in the same run, and also running the individual tests one by one from the command line.
The Foundation framework defines a base layer of functionality that is required for almost all applications. It provides primitive classes and introduces several paradigms that define functionality not provided by either the Objective-C runtime and language or Swift standard library and language.
It is designed with these goals in mind:
There is more information on the Foundation framework here.
This project, swift-corelibs-foundation
, provides an implementation of the Foundation API for platforms where there is no Objective-C runtime. On macOS, iOS, and other Apple platforms, apps should use the Foundation that comes with the operating system. Our goal is for the API in this project to match the OS-provided Foundation and abstract away the exact underlying platform as much as possible.
Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
Therefore, we are not looking to make major API changes to the library that do not correspond with changes made to Foundation on Apple platforms. However, there are some areas where API changes are unavoidable. In these cases, documentation on the method will provide additional detail of the reason for the difference.
For more information on those APIs and the overall design of Foundation, please see our design document.
See our status page for a detailed list of what features are currently implemented.
Here is a simple main.swift
file which uses Foundation. This guide assumes you have already installed a version of the latest Swift binary distribution.
import Foundation // Make a URLComponents instance let swifty = URLComponents(string: "https://swift.org")! // Print something useful about the URL print("\(swifty.host!)") // Output: "swift.org"
You will want to use the Swift Package Manager to build your Swift apps.
For information on how to build Foundation, please see Getting Started. If you would like, please consult our status page to see where you can make the biggest impact, and once you're ready to make changes of your own, check out our information on contributing.
We believe that the Swift standard library should remain small and laser-focused on providing support for language primitives. The Foundation framework has the flexibility to include higher-level concepts and to build on top of the standard library, much in the same way that it builds upon the C standard library and Objective-C runtime on Darwin platforms.
There are several reasons why these types are useful in Swift as distinct types from the ones in the standard library:
In general, the dividing line should be drawn in overlapping area of what people consider the language and what people consider to be a library feature.
For example, Optional is a type provided by the standard library. However, the compiler understands the concept to provide support for things like optional-chaining syntax. The compiler also has syntax for creating Arrays and Dictionaries.
On the other hand, the compiler has no built-in support for types like URL
. URL
also ties into more complex functionality like basic networking support. Therefore this type is more appropriate for Foundation.
Foundation on Darwin is written primarily in Objective-C, and the Objective-C runtime is not part of the Swift open source project. CoreFoundation, however, is a portable C library and does not require the Objective-C runtime. It contains much of the behavior that is exposed via the Foundation API. Therefore, it is used on all platforms including Linux.
We welcome contributions to Foundation! Please see the known issues page if you are looking for an area where we need help. We are also standing by on the mailing lists to answer questions about what is most important to do and what we will accept into the project.