second_curtain alternatives and similar libraries
Based on the "Other Testing" category.
Alternatively, view second_curtain alternatives based on common mentions on social networks and blogs.
-
PonyDebugger
Remote network and data debugging for your native iOS app using Chrome Developer Tools -
iOS Snapshot Test Case
Snapshot view unit tests for iOS -
ios-snapshot-test-case
Snapshot view unit tests for iOS -
Mockingjay
An elegant library for stubbing HTTP requests with ease in Swift -
OCMockito
Mockito for Objective-C: creation, verification and stubbing of mock objects -
Buildasaur
Automatic testing of your Pull Requests on GitHub and BitBucket using Xcode Server. Keep your team productive and safe. Get up and running in minutes. @buildasaur -
Kakapo
🐤Dynamically Mock server behaviors and responses in Swift -
NaughtyKeyboard
The Big List of Naughty Strings is a list of strings which have a high probability of causing issues when used as user-input data. This is a keyboard to help you test your app from your iOS device. -
trainer
Convert xcodebuild plist and xcresult files to JUnit reports -
Cribble
Swifty tool for visual testing iPhone and iPad apps. Every pixel counts. -
Mockingbird
Simplify software testing, by easily mocking any system using HTTP/HTTPS, allowing a team to test and develop against a service that is not complete or is unstable or just to reproduce planned/edge cases. -
Mockit
A simple mocking framework for Swift, inspired by the famous http://mockito.org/ -
MirrorDiffKit
Graduation from messy XCTAssertEqual messages. -
AcceptanceMark
Tool for generating Acceptance Tests in Xcode, inspired by Fitnesse -
MetovaTestKit
A collection of useful test helpers designed to ease the burden of writing tests for iOS applications. -
SnappyTestCase
iOS Simulator type agnostic snapshot testing, built on top of the FBSnapshotTestCase. -
XCTestExtensions
XCTestExtensions is a Swift extension that provides convenient assertions for writing Unit Test. -
TestKit
The easiest way to implement full BDD in your Swift iOS projects! Use plain English specs (Gherkin) to drive tests that include both UI automation and interacting with application data & state. -
Bugfender Live
Stream the screen of an iOS device for live debugging. -
Parallel iOS Tests
Run iOS tests on multiple simulators in parallel at the same time
Appwrite - The Open Source Firebase alternative introduces iOS support
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of second_curtain or a related project?
README
Second Curtain
If you're using the cool FBSnapshotTestCase to test your iOS view logic, awesome! Even better if you have continuous integration, like on Travis, to automate running those tests!
Purpose
Isn't it frustrating that you can't see the results of your tests? At best, you'll get this kind of error output:
ASHViewControllerSpec
a_view_controller_with_a_loaded_view_should_have_a_valid_snapshot, expected a matching snapshot in a_view_controller_with_a_loaded_view_should_have_a_valid_snapshot
/Users/travis/build/AshFurrow/upload-ios-snapshot-test-case/Demo/DemoTests/DemoTests.m:31
it(@"should have a valid snapshot", ^{
expect(viewController).to.haveValidSnapshot();
});
Executed 1 test, with 1 failure (1 unexpected) in 0.952 (0.954) seconds
** TEST FAILED **
Wouldn't it be awesome if we could upload the failing test snapshots somewhere, so we can see exactly what's wrong? That's what we aim to do here.
Usage
Usage is pretty simple. Have an S3 bucket that is world-readable (that is, include the following bucket policy).
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "AllowPublicRead",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
(Replace "bucket-name" with your bucket name.)
It's also a good idea not to use a general-purpose S3 user for your CI, so create a new one with the following policy that will let them list buckets, but only read from or write to the bucket you're using.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListAllMyBuckets"],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::bucket-name"
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
OK, so the hard part is mostly done. Now that we have a place to upload our images, let's configure our build.
I use a Makefile to build and run tests on my iOS project, so my .travis.yml
file looks something like this:
language: objective-c
cache: bundler
env:
- UPLOAD_IOS_SNAPSHOT_BUCKET_NAME=bucket-name
- UPLOAD_IOS_SNAPSHOT_BUCKET_PREFIX=an/optional/prefix
- AWS_ACCESS_KEY_ID=ACCESS_KEY
- AWS_SECRET_ACCESS_KEY=SECRET_KEY
- AWS_REGION=OPTIONAL_REGION_DEFINITION
before_install:
- bundle install
before_script:
- export LANG=en_US.UTF-8
- make ci
script:
- make test
(You can take a look at how to encrypt information in your config file, but this has limitations due to how ecrypted variables are accessed via PRs on forks.)
My Makefile looks like this:
WORKSPACE = Demo/Demo.xcworkspace
SCHEME = Demo
all: ci
build:
set -o pipefail && xcodebuild -workspace $(WORKSPACE) -scheme $(SCHEME) -sdk iphonesimulator build | xcpretty -c
clean:
xcodebuild -workspace $(WORKSPACE) -scheme $(SCHEME) clean
test:
set -o pipefail && xcodebuild -workspace $(WORKSPACE) -scheme $(SCHEME) -configuration Debug test -sdk iphonesimulator | second_curtain | xcpretty -c --test
ci: build
Notice that we're piping the output from xcodebuild
into second_curtain
.
Note also that we're using xcpretty
, as you should, too. The xcpretty
invocation must come after the second_curtain
invocation, since Second Curtain relies on parsing the output from xcodebuild
directly.
And finally, our Gemfile:
source 'https://rubygems.org'
gem 'cocoapods'
gem 'xcpretty'
gem 'second_curtain', '~> 0.2'
And when any snapshot tests fail, they'll be uploaded to S3 and an HTML page will be generated with links to the images so you can download them. Huzzah!
Note that when the S3 directory is created, it needs to be unique. You can provide a custom folder name with the UPLOAD_IOS_SNAPSHOT_FOLDER_NAME
environment variable. If one is not provided, Second Curtain will fall back to TRAVIS_JOB_ID
or CIRCLE_BUILD_NUM
, and then onto one generated by the current date and time.