Skip to content

Latest commit

 

History

History
109 lines (64 loc) · 4.24 KB

Testing.md

File metadata and controls

109 lines (64 loc) · 4.24 KB

Testing fastlane

Testing your local changes

Checking it all

The Fastfile included at the top of the fastlane project allows you to run several validation steps, such as automated tests, code style and more.

bundle exec fastlane test

You can also run those steps independently or on a more fine-grained way.

Automated tests

Make sure to run the automated tests using bundle exec to ensure you’re running the correct version of rspec and rubocop

All unit tests

First, navigate into the root of the fastlane project and run all unit tests using

bundle exec rspec

Unit tests for one specific tool

If you want to run tests only for one tool, use

bundle exec rspec [tool_name]

Unit tests in one specific test file

If you know exactly which _spec.rb file you want to run, use

bundle exec rspec ./fastlane/spec/fastlane_require_spec.rb

Replace ./fastlane/spec/fastlane_require_spec.rb with the path of your test file of course.

Specific unit test (group) in a specific test file

If you know the specific unit test or unit test group you want to run, use

bundle exec rspec ./fastlane/spec/fastlane_require_spec.rb:17

The number is the line number of the unit test (it ... do) or unit test group (describe ... do) you want to run.

Instead of using the line number you can also use a filter with the it "something", now: true notation and then use bundle exec rspec -t now to run this tagged test. (Note that now can be any random string of your choice.)

Code style

To verify and auto-fix the code style

bundle exec rubocop -a

If you want to run code style verification only for one tool, use bundle exec rubocop -a [tool_name]

FastlaneSwiftRunner

If you'd like to see your changes reflect on FastlaneSwiftRunner, the Swift set of APIs, you need to update the auto-generated Swift APIs locally. You can do that by running bundle exec fastlane generate_swift_api. Once this is done, you can test your local fastlane code base with your setup.

Do not commit the changes generated by the generate_swift_api command, as this is part of the release process of a new version of fastlane, so your PR shouldn't include those changes.

If you need to see any output from FastlaneSwiftRunner, activate the flag --verbose when launching FastlaneSwiftRunner or any of its lanes.

Remember that to debug FastlaneSwiftRunner on Xcode, you can set a flag to wait for the executable to be launched by fastlane. You can go to next path and set a tick on Scheme → FastlaneSwiftRunner → Run → Launch → Wait for the executable to be launched.

Test your local fastlane code base with your setup

After introducing some changes to the fastlane source code, you probably want to test the changes for your application. The easiest way to do so it use bundler.

Edit your Gemfile in your project's root folder and replace the gem 'fastlane' line with:

gemspec path: File.expand_path("<PATH_TO_YOUR_LOCAL_FASTLANE_CLONE>")

If you don't have a Gemfile yet, copy the Gemfile .assets/Gemfile from your local fastlane clone and drop it into your project's root folder.

Make sure to replace <PATH_TO_YOUR_LOCAL_FASTLANE_CLONE> with the path to your fastlane clone, e.g. ~/fastlane, then you can run

bundle update

in your project’s root directory. After doing so, you can verify you’re using the local version by running

bundle info fastlane

which should print out the path to your local development environment.

From now on, every time you introduce a change to your local fastlane code base, you can immediately test it by running bundle exec fastlane …. (Note that just using fastlane … without bundle exec will not use your local fastlane code base!)

If you want to run a command with your normal fastlane installation, simply do not run the command with the bundle exec prefix.

To completely remove fastlane from your local project, delete the Gemfile you created earlier, or undo the changes you made to match the Gemfile template.