Library Modulepointfreeco.xctest-dynamic-overlay 1.5.1IssueReporting

IssueReporting

Report issues in your application and library code as Xcode runtime warnings, breakpoints, assertions, and do so in a testable manner.

IssueReporting.md
import IssueReporting

Module information

Declarations
52
Symbols
64

Coverage

63.5 percent of the declarations in IssueReporting are fully documented23.1 percent of the declarations in IssueReporting are indirectly documented13.5 percent of the declarations in IssueReporting are completely undocumented

Declarations

36.5 percent of the declarations in IssueReporting are global functions or variables1.9 percent of the declarations in IssueReporting are operators15.4 percent of the declarations in IssueReporting are initializers, type members, or enum cases15.4 percent of the declarations in IssueReporting are instance members1.9 percent of the declarations in IssueReporting are protocols7.7 percent of the declarations in IssueReporting are protocol requirements5.8 percent of the declarations in IssueReporting are default implementations15.4 percent of the declarations in IssueReporting are structures

Interfaces

88.5 percent of the declarations in IssueReporting are unrestricted11.5 percent of the declarations in IssueReporting are underscored
Module stats and coverage details

Overview

This library provides robust tools for reporting issues in your application with a customizable degree of granularity and severity. In its most basic form you use the unified reportIssue function anywhere in your application to flag an issue in your code, such as a code path that you think should never be executed:

guard let lastItem = items.last
else {
  reportIssue("'items' should never be empty.")
  return 
}
// ...

By default, reportIssue will trigger an unobtrusive, purple runtime warning when running your app in Xcode (simulator and device):

A purple runtime warning in Xcode showing that an issue has been reported.

This provides a very visible way to see when an issue has occurred in your application without stopping the app’s execution and interrupting your workflow.

The reportIssue tool can also be customized to allow for other ways of reporting issues. It can be configured to trigger a breakpoint if you want to do some debugging when an issue is reported, or a precondition or fatal error if you want to truly stop execution. And you can create your own custom issue reporter to send issues to OSLog or an external server.

Further, when running your code in a testing context (both XCTest and Swift’s native Testing framework), all reported issues become test failures. This helps you get test coverage that problematic code paths are not executed, and makes it possible to build testing tools for libraries that ship in the same target as the library itself.

A test failure in Xcode where an issue has been reported.

Essentials

Reporting issues

Issue reporters

Custom reporting

Testing

  • let isTesting: Bool

    Whether or not the current process is running tests.

  • enum TestContext

    A type representing the context in which a test is being run, i.e. either in Swift’s native Testing framework, or Xcode’s XCTest framework.

Unimplemented