KZAsserts alternatives and similar libraries
Based on the "Code Quality" category.
Alternatively, view KZAsserts alternatives based on common mentions on social networks and blogs.
-
chisel
Chisel is a collection of LLDB commands to assist debugging iOS apps. -
SwiftFormat
A command-line tool and Xcode Extension for formatting Swift code -
MLeaksFinder
Find memory leaks in your iOS app at develop time. -
FBRetainCycleDetector
iOS library to help detecting retain cycles in runtime. -
FBMemoryProfiler
iOS tool that helps with profiling iOS Memory usage. -
OCLint
A static source code analysis tool to improve quality and reduce defects for C, C++ and Objective-C -
CleanArchitectureRxSwift
Example of Clean Architecture of iOS app using RxSwift -
Dotzu
iOS app debugger while using the app. Crash report, logs, network. -
HeapInspector-for-iOS
Find memory issues & leaks in your iOS app without instruments -
dotenv-linter
⚡️Lightning-fast linter for .env files. Written in Rust 🦀 -
spacecommander
Commit fully-formatted Objective-C as a team without even trying. -
IBAnalyzer
Find common xib and storyboard-related problems without running your app or writing unit tests. -
ODUIThreadGuard
A guard to help you check if you make UI changes not in main thread -
DWURecyclingAlert
Optimizing UITableViewCell For Fast Scrolling -
SwiftCop
SwiftCop is a validation library fully written in Swift and inspired by the clarity of Ruby On Rails Active Record validations. -
Warnings-xcconfig
An xcconfig (Xcode configuration) file for easily turning on a boatload of warnings in your project or its targets. -
Marshroute
Marshroute is an iOS Library for making your Routers simple but extremely powerful -
PSTModernizer
Makes it easier to support older versions of iOS by fixing things and adding missing methods -
Trackable
Trackable is a simple analytics integration helper library. It’s especially designed for easy and comfortable integration with existing projects. -
DecouplingKit
decoupling between modules in your iOS Project. iOS模块化过程中模块间解耦方案 -
AnyLint
Lint anything by combining the power of scripts & regular expressions. -
WeakableSelf
A Swift micro-framework to easily deal with weak references to self inside closures -
SwiftLinter
Share lint rules between projects and lint changed files with SwiftLint. -
UIBaseKit
This helps make the view's configuration code, hierarchy code, and constraint code neat. -
Bugsee
In-app bug and crash reporting with video, logs, network traffic and traces.
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 KZAsserts or a related project?
README
KZAsserts - Asserts on roids, test all your assumptions with ease.
There are many ways in which we can improve quality of our code-base, Assertions are one of them. Yet very few people actually use asserts, why is that?
An assert is used to make certain that a specific condition is true, because our apps don't exist in a vacuum and we often work with other API's (or our own), we need to make sure our assumptions about it are actually valid or we might have really weird bugs.
If our assumption is wrong, assert will crash on the line that checks that condition thus allowing us to find bugs in our code very quickly.
This is great concept, crash early and crash often, it makes it easy to have clean and bug free code.
On the other hand Release build should avoid crashing whenever possible, unless you like 1-star rating?
Because of that normal assertions are not enough, you need to make sure your code handles errors even in release builds, if you just strip assertions from release you are still going to crash if your assumption was wrong (eg. after striping asserts you'll have code that mismatches types etc.)!
How great would it be to assert all assumptions regarding server API responses, so that if backend changes you know it immediately and you can fix your code? So people end up with something like this:
NSParameterAssert([dataFromServer isKindOfClass:[NSDictionary class]]);
if ([dataFromServer isKindOfClass:[NSDictionary class]]) {
//! create NSError, handle it
}
NSParameterAssert([something isKindOfClass:[NSString class]]);
if ([something isKindOfClass:[NSString class]]) {
//! create NSError, handle it
}
Obviously they could store that condition once and reuse it in assert and if statement, it still sucks!
Now imagine testing your whole response format, that would be so much unnecesary and hard to read code!
That's why I've come up with KZAsserts around 2 years ago, this is how that could can look:
AssertTrueOrReturnError([dataFromServer isKindOfClass:[NSDictionary class]]);
AssertTrueOrReturnError([something isKindOfClass:[NSString class]]);
This will crash in debug, but in release it will automatically generate NSError for you, it will then return that error object from the current scope. It can also log message to your logger / server / console: [IMAGE](../master/Log.png?raw=true)
And that's not all, you probably write a lot of async code in your apps? KZAsserts handles that as easily:
- (void)downloadFromURL:(NSURL*)url withCompletion:(void (^)(NSData *, NSError *))completionBlock
{
AssertTrueOrReturnNilBlock([something isKindOfClass:[NSString class]], ^(NSError *error) {
completionBlock(nil, error);
});
//! ...
}
With those kind of macros, you can now assert all your assumptions. I'd also encourage you to use Asserts for enforcing API contracts: eg. if you have a method that downloads NSData * and the only way to get the results is via completion block, you should assert there actually is completion block. Otherwise you are wasting your user battery/network.
Assert macros
KZAsserts provies following asserts:
AssertTrueOr[X](condition) - if condition fails to be true, on debug builds it will crash by using Assertion, on Release builds it calls error creation and perform specific action. Asserts with block param will execute ^(NSError *){} passed in block with auto-generated NSError.
AssertTrueOrReturnError
AssertTrueOrReturnErrorBlock
AssertTrueOrReturn
AssertTrueOrReturnBlock
AssertTrueOrReturnNo
AssertTrueOrReturnNoBlock
AssertTrueOrReturnNil
AssertTrueOrReturnNilBlock
AssertTrueOrContinue
AssertTrueOrContinueBlock
AssertTrueOrBreak
AssertTrueOrBreakBlock
Installation
KZAsserts is available through CocoaPods for OSX, iOS and tvOS, to install it simply add the following line to your Podfile:
pod "KZAsserts"
Supplying your own NSError creation function
If you want to have your own NSError creation function you can just add following line on top of your applicationDidFinishLaunching:
[KZAsserts registerErrorFunction:myErrorCreationFunction];
You can also change whole format of logging by defining your own KZAMakeError macro.
Test Assertion flow during debugging
In debug version, the assert aborts the program, sometimes we want quick look, what's will happens in release version. If you adding symbolic breakpoint with action you can check it:
[+[KZAsserts debugPass:] p shouldPass = YES](setup_symbolic_breakpoint.png "+[KZAsserts debugPass:] p shouldPass = YES")
To copy paste, symbol and action:
+[KZAsserts debugPass:]
p shouldPass = YES
Author
Krzysztof Zablocki, @merowing_ my blog
License
KZAsserts is available under the MIT license. See the LICENSE file for more info.
*Note that all licence references and agreements mentioned in the KZAsserts README section above
are relevant to that project's source code only.