Beware of the dancing Gandalf...
🇺🇸 🇺🇸 LOLzwagon 🇺🇸 🇺🇸
Significantly bumps up your iOS XCTest code coverage and makes all unit tests pass... by crippling them
- Looking to get a raise with the least amount of work possible?
- Having to deal with a superior and explain to them on numerous occassions that it's extremely difficult (if not impossible) to get past 95% of code completion in your repo?
- In an office argument with the backened team and want to prove to them that the bug is on their side due to how well tested your code is?
IF YOU SAID "YES" TO ANY OF THE ABOVE, THIS REPO IS FOR YOU!
This code will neuter all
XCTestExpectation functions/methods called on for testing failures. In addition, this dylib will greatly increase the code coverage of all modules which contain code coverage.
Check them pics out!
Download the Xcode project and build the LOLzwagon Xcode scheme.
xcodebuild -project LOLzwagon.xcodeproj -scheme LOLzwagon -sdk iphonesimulator -config Debug
The above example used the Debug scheme, but feel free to also use the Release or the GimmeARaise scheme, but more on that in a sec...
After successfully compiling, the
LOLzwagon dylib will be placed at the following directory:
Make sure you have write access to
/usr/local/lib/ otherwise everything below will fail.
If you load this framework into your process, it will cripple Xcode's Unit Testing!
Bundled into the Xcode project is a scheme called CodeCoverage which includes unit tests. Run these unit tests and observe the
xcodebuild test -project LOLzwagon.xcodeproj -scheme CodeCoverage -enableCodeCoverage YES -destination 'platform=iOS Simulator,OS=12.1,name=iPhone XS' -sdk iphonesimulator -config Debug
The logic in these tests should fail, but OMG, they'll pass!
There are several ways to get this code to run on your 5-year-old CI/CD mac mini and loaded into test builds.
Let's go through some of the ways that you can do this...
- Just compile the
LOLzwagon.mfile into your application. This is definitely not recommended, since your
svn/whatever credentials are tied to your action.
- The second to worst idea is to use the DYLD_INSERT_LIBRARIES environment variable. This environment variable loads framework(s) into a process before anything else is loaded (while still honoring it's
LC_LOAD_DYLIBdependencies first). Again, it's still tied to source control (especially if a shared Xcode scheme), so still not a good idea.
- A more subtle way is to use a launch agent to insert the
DYLD_INSERT_LIBRARIESenvironment variable so it survives outside of source control. Your Jenkins/whatever build machine will likely
git cloneyour repo to a specific directory. You can use a
launchdagent to monitor the directory and perform an action if something changes.
As an example, if you want to monitor changes in the
/tmp/ directory, you can save the following into
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.selander.LOLzwagon</string> <key>ProgramArguments</key> <array> <string>echo</string> <string>Yay! Working!</string> </array> <key>WatchPaths</key> <array> <string>/tmp/testdir</string> </array> <key>StandardOutPath</key> <string>/tmp/log_file.txt</string> </dict> </plist>
Enable this daemon:
launchctl load -w ~/Library/LaunchAgents/com.selander.LOLzwagon.plist
Now, if you open up a new Terminal window, you can watch the events
touch /tmp/log_file.txt && tail -f /tmp/log_file.txt
In the other Terminal, trigger an event
Using this method, you can watch for events and add your environment variables outside of source control. Warning: this is prone to race conditions, you'll need to figure out how to get around that on your oooooooooooowwwwwwwwwn
Debug config will bump the unit tests up considerably in your application, but if you really, really want to shoot high for Code Coverage, you can compile your application with the GimmeARaise Xcode config.
xcodebuild test -project LOLzwagon.xcodeproj -scheme CodeCoverage -sdk iphonesimulator -config GimmeARaise
Warning, this might make your Code Coverage a little too good. Might be better to make it slightly lower to glide under the radar.
How Does it Work?
SDEs & SDETs write some weird shit for testing cases that this repo might not catch. The most problematic scenario might be the
XCTestExpectation classes depending on the crazy stuff you're testing. If you see a failing test case, please report an issue and include a generic test case to show the problem via Swift or Objective-C. Test Driven Development is an important workflow in order to make unit tests not work......
Also, don't use this in a production codebase... or any codebase