https://github.com/derekselander/lolzwagon
Significantly bumps up your iOS XCTest code coverage and makes all unit tests pass... by crippling them
https://github.com/derekselander/lolzwagon
ios lolzwagon macos test testing unittesting volkswagen xcode
Last synced: 11 months ago
JSON representation
Significantly bumps up your iOS XCTest code coverage and makes all unit tests pass... by crippling them
- Host: GitHub
- URL: https://github.com/derekselander/lolzwagon
- Owner: DerekSelander
- Created: 2019-01-28T00:32:22.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2019-02-05T22:00:51.000Z (about 7 years ago)
- Last Synced: 2025-04-02T00:35:54.335Z (12 months ago)
- Topics: ios, lolzwagon, macos, test, testing, unittesting, volkswagen, xcode
- Language: Objective-C
- Homepage:
- Size: 2.55 MB
- Stars: 31
- Watchers: 3
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
Beware of the dancing Gandalf...
🇺🇸🇺🇸 LOLzwagon 🇺🇸🇺🇸
Significantly bumps up your iOS XCTest code coverage and makes all unit tests pass... by crippling them
"You know a repo is legit if it has a logo for it"
Are you...
* 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 `XCTAssert*`/`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!
## Compiling
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:
```
/usr/local/lib/libLOLzwagon.dylib
```
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! 🎉 Check out the **Integrating** section for more info.
## Testing
Bundled into the Xcode project is a scheme called **CodeCoverage** which includes unit tests. Run these unit tests and observe the `XCTest` scenarios.
```
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!
## Integrating
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...
1. Just compile the `LOLzwagon.m` file into your application. This is definitely not recommended, since your `git`/`svn`/whatever credentials are tied to your action.
2. 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_DYLIB` dependencies first). Again, it's still tied to source control (especially if a shared Xcode scheme), so still not a good idea.
3. A more subtle way is to use a **launch agent** to insert the `DYLD_INSERT_LIBRARIES` environment variable so it survives outside of source control. Your Jenkins/whatever build machine will likely `git clone` your repo to a specific directory. You can use a `launchd` agent 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 **`~/Library/LaunchAgents/com.selander.LOLzwagon.plist`**
```
Label
com.selander.LOLzwagon
ProgramArguments
echo
Yay! Working!
WatchPaths
/tmp/testdir
StandardOutPath
/tmp/log_file.txt
```
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
```
mkdir /tmp/testdir
```
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
## Code Coverage
Building the `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?
LOL
## Bugs
SDEs & SDETs write some weird shit for testing cases that this repo might not catch. The most problematic scenario might be the `XCTestCase` and `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