Tag Archives: thread

Functional Coverage and Coverpoints

Posted on April 10, 2013 | 1 comment

I recently posted an article called Setting up and using Code Coverage.   As I mentioned there, code coverage is useful for seeing what portions of your code have been exercised.    What code coverage can’t do though is to ensure functional correctness – this is where functional coverage comes into play. Functional coverage allows you to determine when you have exposed your code to a sufficient enough set of stimulus, including hitting corner cases,  that you have a high confidence in its functionality.

My background includes experience as a hardware verification engineer, where the teams I was part of used both code coverage and functional coverage as essential tools in test development.     In the Wikipedia section on SystemVerilog (a hardware description and verification language) there is a nice write-up on Coverage where the difference between code coverage and functional coverage is discussed.

What is a Coverpoint?

I wanted to employ some functional coverage as a guide to my unit test development.   In the SystemVerilog language mentioned above, they have the concept of coverpoints and covergroups (group of coverpoints).   I found a nice document called SystemVerilog Testbench Automation Tutorial where there is some good information about these concepts starting in the section titled “Functional Coverage”.

A coverpoint is essentially a measurement point where an event (such as values taken on by a variable) can be recorded, along with bins for how many times specific values (or range of values) occurred for that event.

Continue reading →

Advertisements

1 Comment

Posted in testing

Tagged , , , , , , ,

Unit Testing View Controllers and Asynchronous APIs

Posted on April 9, 2013 | 3 comments

I have an application that I’m working on that uses Parse (a service that lets you persist objects in the cloud, perform queries, etc.).    Calls to the Parse APIs are initiated from the main thread and dispatched to the global queue, thus  completion of these calls happens asynchronously.

I wanted to write some unit tests to verify the functionality of my methods that interface with Parse.

Referencing the View Controller

My initial view controller is called EntryViewController.   This view controller instances a class called ParseConnection which serves as a model for all my Parse interactions.    All calls to methods in ParseConnection from EntryViewController are dispatched to the global queue.  Within ParseConnection, all the API calls are made synchronously in this background queue.

My first challenge was how to get a reference from my unit tests to EntryViewController.   I wanted to do this from the instance setUp method in my test suite class called ContactsOnlineBasicUnitTests, and store this reference in a property.   This setUp method is called before each test case is run.


@interface  ContactsOnlineBasicUnitTests ()

@property (strong, nonatomic) EntryViewController *entryViewController;

@end

Continue reading →

3 Comments

Posted in testing

Tagged , , , , , ,

Flexible method calls with NSInvocation

Posted on March 3, 2013 | 1 comment

I was recently working on a means to perform concurrent saves (for performance reasons) of some records to Parse .     As I worked through this I realized that there may be some benefit in creating a generic dispatcher that wasn’t tied to a particular source of those records.   My goal was to give this generic dispatcher the means to retrieve a total record count and set of records in a range, without having to know the details of where the count and records came from.

The dispatcher would also be given parameters that told it how many records to save at once (Parse has a saveAll feature for persisting objects to the cloud), along with how many saves to perform concurrently.

Selectors

At first I explored using one or more selectors that I passed from my custom record save method to the generic dispatcher.     I quickly ran into the warning “performSelector may cause a leak because its selector is unknown”.  I found an excellent post on Stack Overflow that discusses this issue.  One proposed explanation for this warning was that since the selector is unknown to the compiler, ARC cannot enforce proper memory management.

Continue reading →

1 Comment

Posted in iOS

Tagged , , , ,

Singletons and synchronized code

Posted on March 2, 2013 | 4 comments

I’ve been making more use of threads and recently needed to allow two threads (neither of them the main thread) to coordinate with each other.    In this particular case I was logging into Parse in one thread and moving some data from the Address Book to Core Data in the other thread.   Once both threads completed, I wanted to call a routine that would allow me to communicate with Parse and update some records in the cloud as needed.

Parse

As an aside, I wanted to put in a quick plug for Parse.  It’s a great service that allows me to persist objects in the cloud, perform queries, etc.   The documentation is great and the team has been very responsive on their forums.  I hope to write about my experience with Parse more extensively in the future.

Singletons

Conceptually, it isn’t difficult to think about how to synchronize the completion of the threads before kicking off my update method.   I just need to keep a flag somewhere that both threads can check.

@property (nonatomic) BOOL readyForParseUpdate;

Continue reading →

4 Comments

Posted in iOS

Tagged , , , , ,