text: Server-Side Swift: Testing on Linux
  In this tutorial, you’ll test your server-side Swift apps on Linux, learning the differences between testing on macOS and Linux, and how to use Docker and Docker Compose.
  Version
  - Swift 4.2, Ubuntu 18.04, Other
  Testing is an important part of the software development process. Writing unit tests and automating them as much as possible allows you to develop and evolve your applications quickly.
  In this tutorial, you’ll learn how to test your server-side Swift apps on Linux. You’ll see what the differences are between testing on macOS and Linux. Finally, you’ll learn how to use Docker and Docker Compose to easily test your apps on Linux locally.. It’s vital that you test your app on the same environment that you deploy. While the situation improves constantly, you must still ensure everything works as expected on Linux.
  Declaring Tests on Linux
  Like all server-side Swift apps, SPM (Swift Package Manager) plays an important part for testing your code. On iOS, Xcode links tests to a specific target. It configures a scheme to use that target and you run tests from within Xcode. The Objective-C runtime scans your project for
  XCTestCases and picks out the methods whose names begin with
  test.
  On Linux, and with SPM, there’s no Objective-C runtime. There’s also no Xcode project to keep track of schemes or tests. You must declare them yourself.
  Getting Started
  To kick things off, start by downloading the materials for this tutorial using the Download Materials button at the top or bottom of this tutorial. The starter project contains a Vapor app with a number of tests. Open Package.swift. You’ll see a test target defined in the
  targets array:
  .testTarget(name: "AppTests", dependencies: ["App"])
  This defines a
  testTarget type with a dependency on
  App. Tests must live in the Tests/
  Checking the Tests
  The tests connect to a PostgreSQL database, with the configuration defined in configure.swift in Sources/App. The tests are expecting a database on port 5432 called vapor-test, which accepts a username of vapor and a password of password. This helps avoid conflicting Docker containers when running the app locally. In Terminal, enter the following:
  docker run --name postgres-test -e POSTGRES_DB=vapor-test \ -e POSTGRES_USER=vapor -e POSTGRES_PASSWORD=password \ -p 5433:5432 -d postgres
  Here’s what this does:
  - Run a new container named postgres-test.
  - Specify the database name, username and password through environment variables.
  - Allow apps to connect to the Postgres server by mapping the external port 5433 to the container’s port 5432.
  - Run the server in the background as a daemon.
  - Use
  Here’s what the commands do:
  - Stop the postgres-test container that you ran your tests in.
  - Delete the postgres-test container now that it’s no longer running.
  LinuxMain.swift
  On macOS,
  swift test still uses Objective-C to find the tests to run. On Linux, there’s no Objective-C runtime to discover your
  XCTestCases. You must point Swift in the right direction.
  LinuxMain.swift is the file that tells where the test cases are on Linux. Swift executes that file when you call
  swift test on Linux. An example for this project is the following:
  import XCTest // 1 @testable import AppTests // 2 XCTMain([ testCase(AcronymTests.allTests), testCase(CategoryTests.allTests), testCase(UserTests.allTests) ])
  This file is the test equivalent of main.swift. Here’s what it does:
  - Import the
  AppTestsmodule, which contains your tests.
  - Provide an array of tests for each
  XCTestCaseto
  XCTMain(_:). These are the tests executed when testing your app on Linux.
  You must provide an array for each
  XCTestCase. By convention, you call this array
  __allTests. It contains a list of tuples consisting of the name of the test and the test itself. For
  UserTests this looks like the following:
  static let __allTests = [ ("testUsersCanBeRetrievedFromAPI", testUsersCanBeRetrievedFromAPI), ("testUserCanBeSavedWithAPI", testUserCanBeSavedWithAPI), ("testGettingASingleUserFromTheAPI", testGettingASingleUserFromTheAPI), ("testGettingAUsersAcronymsFromTheAPI", testGettingAUsersAcronymsFromTheAPI) ]
  When you call
  swift test on Linux, the test executable uses this array to determine which tests to run.
  Generating a Test Manifest
  Currently, you must create and maintain a LinuxMain.swift and the test arrays manually. This leaves a lot of room for error and it’s time consuming. Swift 4.1 introduced a new tool generate-linuxmain to help. In Terminal, from the root folder of the starter project, type the following:
  swift test --generate-linuxmain
  This generates LinuxMain.swift in the Tests directory for you. The command also generates XCTestManifests.swift in Tests/AppTests. This file contains extensions for all test cases in your module, defining each test. This saves time and avoids mistakes when declaring your tests for Linux.
  Running Tests on Linux
  With the test manifest now generated, you can run your tests on Linux. Early feedback is always valuable in software development and running tests on Linux is no exception. Using a Continuous Integration system to automatically test on Linux is vital, but what happens if you want to test on Linux on your Mac?:4.2 # 2 WORKDIR /package # 3 COPY . ./ # 4 RUN swift package resolve RUN swift package clean # 5 CMD ["swift", "test"]
  Here’s what the Dockerfile does:
  - Use the official Swift 4.2 image.
  - Set the working directory to /package.
  - Copy the contents of the current directory into /package in the container.
  - Fetch the dependencies and clean up the project’s build artifacts.
  - Set the default command to
  swift test. This is the command Docker executes when you run the Dockerfile.
  Using Docker Compose
  As described earlier, the tests need a PostgreSQL database in order to run. By default, Docker containers can’t see each other. However, Docker has a tool, Docker Compose, designed to link togetherNAME=postgres - DATABASE_PORT=5432 # 7 postgres: # 8 image: "postgres" # 9 environment: - POSTGRES_DB=vapor-test - POSTGRES_USER=vapor - POSTGRES_PASSWORD=password
  Here’s what this does:
  - Specify the Docker Compose version.
  - Define the services for this app.
  - Define a service for the TIL app.
  - Set a dependency on the Postgres container, so Docker Compose starts the Postgres container first.
  - Build the Dockerfile in the current directory — the Dockerfile you just created.
  - Inject the
  DATABASE_HOSTNAMEenvironment variable. Docker Compose has an internal DNS resolver. This
  allows the
  til-appcontainer to connect to the
  postgrescontainer with the hostname
  postgres. Also set the port for the database to use in tests.
  - Define a service for the Postgres container.
  - Use the standard Postgres image.
  - Set the same environment variables as used at the start of the tutorial for the test database.
  To test your app in Linux, in Terminal, type the following:
  # 1 docker-compose build # 2 docker-compose up --abort-on-container-exit
  Here’s what this does:
  - Build the different Docker containers.
  - Spin. Your Linux machine will need PostgreSQL (as configured in the Docker example above) and the following packages installed: libssl-dev, libz-dev and pkg-config, which you can install via
  sudo apt install libssl-dev libz-dev pkg-config. you to test your server-side Swift apps on Linux to ensure that they work correctly. Making use of!