TweetFollow Us on Twitter

The Road to Code: Passing the Test

Volume Number: 25
Issue Number: 03
Column Tag: Road to Code

The Road to Code: Passing the Test

Automated Unit Testing

by Dave Dribin

Automated Unit Testing

This month's topic is one of my favorites. Once you've written an application, how do you know that it actually works? First, we have to define what we mean by "works." The word "works" means different things to different people. To the developer, "works" may mean "works as intended." To the end user, "works" often means "works as I expect it to work." In an ideal world, the developer's and end user's viewpoint are the same, but unfortunately that's not always the case.

In this article, we're going to concentrate on the developer's perspective. As a developer, how do you know that your application works as intended? The simple answer to this question is: run your application, do all the stuff you would expect a user to do, and see if it fails. Of course, this is very vague. What's "all the stuff you would expect a user to do?" Does this list of stuff come from your memory? Do you write it down, so you can repeat the test after you've made changes? If you do write it down, how detailed is the list? Also, how do you know if anything is failing? Is failure subjective to your mood, or are there hard and fast criteria that describes the failure cases?

The process of running your application to verify correct behavior is called testing. The individual items in the list of stuff that gets run are called tests. Wouldn't it be great if you could write tests that run and verify themselves? As it turns out, this kind of testing exists and is called automated software testing. Done properly, the tests are run automatically, they are verified, and the results are reported. This kind of testing is very powerful because they can be run automatically and on set schedules, from once a night to every time you build your code.

A lot has been written about software testing. Today, there are generally two kinds of automated testing: acceptance tests and unit tests. Acceptance tests are often called black box tests because you write your tests by only testing exposed functionality. You test an application, as a whole, without concern for how it is actually implemented. If you were testing an email application, you might test if you could actually send and receive email messages.

Unit tests are often called white box tests. The scope of unit tests is to test out individual components of an application, i.e. specific classes or libraries. They are called white box, because, as the developer, you can use your knowledge about the implementation to write more thorough tests.

This article is going to discuss unit tests in more depth. We're not going to discuss acceptance tests, automated or otherwise, because unit tests are easier to get started with and have a big payoff. We're going to discus how to write automated unit tests in Objective-C using the OCUnit testing framework and how to integrate them into Xcode.

Unit Testing the Hard Way

Okay, so let's get to the code. Let's take our trusty old Rectangle class and add unit tests to ensure that it is implemented properly. The interface header of the code we are working with is shown in Listing 1.

Listing 1: Initial Rectangle.h

#import <Foundation/Foundation.h>
@interface Rectangle : NSObject <NSCoding>
{
    float _leftX;
    float _bottomY;
    float _width;
    float _height;
}
@property float leftX;
@property float bottomY;
@property float width;
@property float height;
@property (readonly) float area;
@property (readonly) float perimeter;
-  (id)initWithLeftX:(float)leftX
            bottomY:(float)bottomY
             rightX:(float)rightX
               topY:(float)topY;
@end

Even without seeing the implementation file, we can see a few possible things to test. The area and perimeter are calculated, so we could test that those are calculated properly. But we can also see that the width and height are calculated. Our constructor takes two points, the lower-left and upper-right, but exposes the lower-left, width, and height as properties. We could test that the height and width are calculated properly. Finally, our class implements the NSCoding protocol. We could test that our archiving works and that we can unarchive previously archived objects.

Let's start simple and verify that our area calculation is working. How do we write code to do this? We can start by writing a simple command line application as shown in Listing 2.

Listing 2: Rectangle command line test

#import <Foundation/Foundation.h>
#import "Rectangle.h"
int main(int argc, char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    
    Rectangle * rectangle =
        [[Rectangle alloc]   initWithLeftX:0
                                 bottomY:0
                                  rightX:15
                                    topY:10];
    [rectangle autorelease];
    
    printf("area is: %.2f\n", rectangle.area);
    
    [pool drain];
    return 0;
}

All this does is create a rectangle with a width of 15 and height of 10 and print its area to the console. How do we know the area is correct? Well, being the geometry geniuses that we are, we know the area is the width times the height, thus it should be 150. We run the program and see if we get the correct output:

area is: 150.00

Yup, that's correct! The problem here is that our testing process requires a human to be involved. A person needs to run the test, look at the output, and verify that the output is correct. There's a lot of room for error. People can forget to run this test, and the person running the test may not know what the correct output should be, off the top of their head. So let's get the computer more involved here. Let's encode the correct output in the unit test by placing an if statement checking for the correct area:

    if (rectangle.area == 150.0f)
        printf("area test passed\n");
    else
        printf("area test failed\n");

Now, the human operator does not need to know the correct answer, and can just look at the output for "passed" vs. "failed." Of course, we still need a human to look at the output, which is less than ideal.

We 'd like to have a better way to indicate failure if the area is not correct. Fortunately, there is the concept of assertions. Assertions are conditions that must be true, in order for a computer program to continue execution. The C language has a function called assert that will terminate the program if the condition fails. We could replace our if statement with this:

    assert(rectangle.area == 150.0f);

This does nothing if the condition is true, but terminates the program if the condition is false. To show you what happens when an assertion fails, let me change that line of code to verify against 100, instead of 150. Running with a failed assertion will result in the following console ouput:

Assertion failed: (rectangle.area == 100.0f), function main, file unit_test.m, line 15.

I've truncated the output a bit, but you can see that it prints the failed condition, along with the filename and line number that the failure occurred on. A person running this test program just needs to ensure that the program runs successfully. If they see any assertion failures, they know that a test has failed, and they can investigate further.

At this point, we can beef up our unit tests a bit. Let's add an assertion for the perimeter, too. Our whole unit test application would now look like Listing 3.

Listing 3: Command line app with assertions

#import <Foundation/Foundation.h>
#import "Rectangle.h"
int main(int argc, char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    
    Rectangle * rectangle =
        [[Rectangle alloc] initWithLeftX:0
                                 bottomY:0
                                  rightX:15
                                    topY:10];
    [rectangle autorelease];
    
    assert(rectangle.area == 150.0f);
    assert(rectangle.perimeter == 50.0f);
    
    [pool drain];
    return 0;
}

We could continue further by adding more and more assertions in our main function, but this would soon get unwieldy. We'd be creating lots of unrelated objects and the code would get quite long. Sure, we could break up the parts of the test into individual functions, however it'd be even better to encapsulate our unit tests inside classes.

Let's say we create a RectangleTest class. We could then have methods to test for the different aspects of the Rectangle class:

@implementation RectangleTest

- (void)testArea
{
    Rectangle * rectangle =
        [[Rectangle alloc] initWithLeftX:0
                                 bottomY:0
                                  rightX:15
                                    topY:10];
    [rectangle autorelease];
    assert(rectangle.area == 150.0f);
}
- (void)testPerimeter
{
    // ...
}
@end

Our main function could just instantiate an instance of this class and call each of the test methods:

    RectangleTest * rectangleTest = [[RectangleTest alloc] init];
    [rectangleTest testArea];
    [rectangleTest testPerimeter];
    [rectangleTest release];

This restructuring of our code is a nice improvement. However, our main function is still bound to get a little unwieldy. If we have tens or hundreds of test classes, each with many test methods, that's a lot of tedious code to write.

Wouldn't it be great if we could just automatically find every test class and automatically call each method that begins with the string "test"? Fortunately, we are not the first people to think this would be a good idea, and someone has already done this work for us. There is a project called OCUnit that does just this!

Using OCUnit from within Xcode

OCUnit is a framework designed to make writing and running unit tests in Objective-C easier. Frameworks, like OCUnit, that assist writing unit tests are called testing frameworks. Testing frameworks exist in many different languages for many different programming environments. Probably the most popular testing framework is called JUnit for writing unit tests in Java, written by Kent Beck and Erich Gamma. JUnit itself is a Java port of a framework called SUnit, which was written for Smalltalk also by Kent Beck. JUnit has spawned many testing frameworks that follow similar principals, and even share similar names, for example CPPUnit for C++ and NUnit for C#. As Objective-C users, we have OCUnit. These JUnit-style testing frameworks are collectively called xUnit testing frameworks.

Luckily for us, OCUnit is included as part of a standard Xcode installation. You don't need to download or install anything. There's even a file template for creating a new unit test class, as shown in Figure 1. OCUnit is also called SenTestingKit because the project started at a company called Sen:Te. You will see this heritage more as we dig into the code. That's why, for example, the file template includes the <SenTestingKit/SenTestingKit.h> header file.


Figure 1: New test case class template

Before creating some unit tests, we need to talk about our code organization a bit. Where should our unit test classes go? Do we need to create a separate GUI or command line application? If so, how do we run our tests? Xcode provides a special target for unit tests called a unit test bundle.

To create a unit test bundle, select the Project > New Target... and chose Unit Test Bundle from the Cocoa section, as shown in Figure 2. Click Next and use UnitTests as the target name.


Figure 2: New Unit Test Bundle target

So now that we have a unit test bundle, how do we run the tests? Bundles in Mac OS X are neither applications nor frameworks. They're just a module of loadable code, so they cannot be run directly. Xcode comes with an application that loads these test bundles, automatically runs all your tests, and prints the results. The Unit Test Bundle target template automatically sets this up for you.

We need to add some unit test classes to this target to fully demonstrate this, so let's create a new Objective-C test class case using the file template and add it to our UnitTests target. Name this class RectangleTest, since we want to test the Rectangle class, as shown in Figure 3. I always name my test classes the same as the class that they're testing plus a "Test" suffix. This indicates that these are indeed a test class, but also which class is being tested.


Figure 3: Creating RectangleTest class

Let's take a look at what this file template created for us. The header file is shown in Listing 4.

Listing 4: Initial RectangleTest.h

#import <SenTestingKit/SenTestingKit.h>
@interface RectangleTest : SenTestCase {
}
@end

In order for OCUnit to help us out, we do need to follow a few rules. The first rule is that all test classes must derive from SenTestCase instead of NSObject, as shown in the header file. Using SenTestCase allows for OCUnit to find every unit test class easily and provides some base functionality that we can build upon. The implementation file initially contains no methods. The second rule is that test methods must begin with the string "test". OCUnit will automatically call every one of these test methods for us.

Inside each test method, we can include assertions that verify that a test passed. However, we cannot use the standard C assert function. The final rule is that we must use OCUnit's special assert functions. Let's create a simple test method, just to demonstrate how this works.

- (void)testAssertions
{
    STAssertTrue(1 == 1, @"Testing value of 1");
}

The STAssertTrue assertion function is very similar to the standard C assert function except it has an extra argument for a message. To run this test and verify the assertion, all you have to do is build the UnitTests build target. We've never had an Xcode project that has had multiple build targets before, so let's go over how to choose a build target. The easiest way, in my opinion, is to use the Overview toolbar button. From this pulldown menu, chose UnitTests under Active Target, as in Figure 4. The active target is the target that gets built when you select the Build > Build menu or use Command-B. By changing the active target, we are telling Xcode to build the unit test bundle instead of our application.


Figure 4: Changing the Active Target

With the new active target selected, we can now build it. It should build successfully, and at first it doesn't look any different than building an application. If you open up the Build Results window (Command-Shift-B), and you show the build transcript, as in Figure 5, you'll see that it actually runs your tests, too.


Figure 5: Build transcript

You can see that it's running the testAssertions test case of RectangeTest and that it passed. You'll even get a summary of how many tests passed and failed and how long they took to run:

Test Suite '/tmp/build/Debug/UnitTests.octest(Tests)' started at 2009-01-22 12:47:28 -0600
Test Suite 'RectangleTest' started at 2009-01-22 12:47:28 -0600
Test Case '-[RectangleTest testAssertions]' passed (0.000 seconds).
Test Suite 'RectangleTest' finished at 2009-01-22 12:47:28 -0600.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
Test Suite '/tmp/build/Debug/UnitTests.octest(Tests)' finished at 2009-01-22 12:47:28 -0600.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.003) seconds

Normally, you don't need to look at the build transcript. You can just assume that a successful build means all your tests passed. But what happens when a test assertion fails? Let's try this out by causing our assertion to fail:

- (void)testAssertions
{
    STAssertTrue(1 == 42, @"Testing value of 1");
}

As 1 obviously isn't equal to 42, this assertion will fail. Now, build the test bundle, again. You'll notice that the build fails. The code actually compiles, but a failing assertion causes the build to fail. You'll see an error bubble and you'll also see an error in your Build Results window, as in Figure 6.


Figure 6: Failing build due to an assertion

The build error message looks just like a compiler error, but the message indicates it's a failed assertion:

error: -[RectangleTest testAssertions] : "1 == 42" should be true. Testing value of 1

This error message gives us the test method that failed, along with a handy message telling us what failed. It also includes the message we added to the assertion. You can click on the error message, and it will bring you right to the line of code where the assertion failed, as well.

Writing Some Real Tests

Now that we've got our unit test bundle in place and we have Xcode setup to run our tests and verify our assertions, we can start writing some real unit tests. Change the RectangleTest implementation to match Listing 5.

Listing 5: RectangleTest.m with real tests

#import "RectangleTest.h"
#import "Rectangle.h"
@implementation RectangleTest
- (void)testArea
{
    Rectangle * rectangle =
        [[Rectangle alloc]   initWithLeftX:0
                                 bottomY:0
                                  rightX:15
                                    topY:10];
    [rectangle autorelease];
    
    STAssertEqualsWithAccuracy(rectangle.area, 150.0f, 0.01, nil);
}
- (void)testPerimeter
{
    Rectangle * rectangle =
          [[Rectangle alloc] initWithLeftX:0
                                 bottomY:0
                                  rightX:15
                                    topY:10];
    [rectangle autorelease];
    
    STAssertEqualsWithAccuracy(rectangle.perimeter, 50.0f, 0.01, nil);
}
@end

This looks very similar to our earlier testArea method except that we use an OCUnit assertion function, STAssertEqualsWithAccuracy, instead of assert. One nice thing about OCUnit is that it comes with a bunch of different assertion functions, not just STAssertTrue. See the Xcode documentation for a full list of assertions functions, but some of the most common ones are:

STAssertEquals
STAssertEqualObjects
STAssertNil

This particular assertion function works a little differently than STAssertTrue. It takes four different arguments: an actual value, an expected value, an accuracy delta, and a message. It tests for equality of floating point numbers by comparing the actual and expected values. But because a computer cannot exactly represent floating point numbers, we need to include an accuracy delta that takes care of this slop. In our assertion, if rectangle.area returns 150 plus or minus 0.01, i.e. between 149.99 and 150.01, then the assertion will pass. We are not including an assertion message, hence the final nil.

Before building our test bundle again to watch our tests pass, we need to include the Rectangle class in our UnitTests target. You can do this by double clicking on the Rectange.m file in the Groups & Files section of Xcode. Switch the Targets tab, and check the checkbox next to the UnitTests bundle, as in Figure 7. This means that Rectangle.m will be compiled and linked into the UnitTests bundle.


Figure 7: Modifying Rectangle.m targets

Now, when you build the UnitTests target, it should build successfully. This means our code compiled and our unit tests pass. Just to verify that all is work, let's change the expected value of our area to be 140. Now when we build, you should get a build error:

error: -[RectangleTest testArea] : '150.000000' should be equal to '140.000000' + or - '0.01':

The nice thing about this error message is that it shows you what the actual and expected values are. This can help determine why a test is failing without using a debugger.

Switch the assertion back to 150 so we have passing tests and now revel in the fact that we have some unit tests for our Rectangle class.

Running Unit Tests for Every Build

One problem with our unit test bundle is that we must remember to change the active target, otherwise it will not get built. I really want to setup Xcode such that our unit tests get run, even when we building our main Rectangles application target. We can do this with target dependencies.

In Xcode, a target can be dependent on another target. This means one target will not get built until another target builds successfully. We're going to use this to make our Rectangles application target dependent on the UnitTests bundle target. Thus, our application will only get built if our unit tests pass.

Open up the Targets section of the Groups & Files section, and double click on the Rectangles application target. With the General tab selected, you should see a list called Direct Dependencies. This is initially empty, but click on the plus button to add a dependency. Select UnitTests and then click on Add Target button. The result is shown in Figure 8.


Figure 8: Adding a target dependency

Now change the active target in the Overview pulldown of the toolbar to be Rectangles, again. When you build this target, it will first build the UnitTests target. If any unit tests fail, it won't even try to build the application. This is a nice setup, so long as the unit tests run fast enough. And proper unit tests should run fast, so fast you won't even notice they're getting run. We can now add more unit test methods to our RectangleTest class to ensure our Rectangle class is working properly.

Dependent Test Bundle

The Xcode documentation describes two kinds of unit test bundles: dependent and independent. What I described above is called independent test bundles by the documentation. The unit test bundle is completely independent from the main application. The Xcode documentation recommends the dependent variation, though. Having tried the dependent variation, I do not recommend it. Dependent tests run your application in a special "test" mode, where it launches your application, and then it loads and starts the unit tests, before the application is fully initialized. The problem I've found is that parts of your application end up running, and the program can get into some weird states. Also, dependent tests do not work for testing frameworks, command line applications, or static libraries.

The only downside of independent tests mentioned in the documentation is that tests must be run manually. As I showed above, you can work around this by setting up target dependencies. Another downside to independent tests is that code being tested needs to be compiled into both the application target as well as the unit test target. Using a static library for this common code can easily mitigate this problem. How to setup a static library is unfortunately beyond the scope of this article, but I can assure you it's not very difficult.

Why Unit Test

We've talked what unit testing is and how to write unit tests, and now I want to talk a little bit more about why you should write unit tests. As I mentioned earlier, unit tests typically target individual classes. If you verify that each individual class works as intended, there's a high probability that your application as a whole will work, at least from the developer's viewpoint. Of course, unit testing isn't perfect. Even if you verified that every class works in isolation, when you assemble individual classes into an application, things may not work so well. If you really want to test the final, assembled application, you'll need to work with acceptance tests. Unit tests, however, are easier to write and run than acceptance tests, and you can still test a vast majority of your application with them. But even if you can't perfectly test your application, you can get an enormous benefit by having unit tests alone.

One of the hidden benefits of writing unit tests is that it improves the quality of your code. In order to be tested in isolation, classes need to be written and designed for testability. The attributes that make your code more testable are the same attributes that make your code high quality and clean. Clean code is a very subjective term, but I think most engineers can agree what ugly code looks like. Large classes with tons of methods, highly coupled and interdependent classes than cannot be pulled out from your application individually, and classes that are hard to understand are all good examples of ugly. We're veering off into object-oriented design, but this is important stuff for real-world applications.

Unit testing is also essential for refactoring. Refactoring is the act of making small changes to your application in order to make improvements. The idea is that these small improvements can significantly increase the code quality of your application. Even though refactoring only makes small changes to your application, these changes can still have unintended side effects resulting in broken code. However, having automated unit tests can provide a safeguard. If your tests pass after you've completed your refactoring, you've gained confidence that you haven't broken anything.

Conclusion

Unit testing and testing as a whole is a large topic. Many books have been written on the topic. We've covered the basics of how to write and execute unit tests in Xcode with OCUnit. I'm sure we'll be seeing more of unit testing in future articles.


Dave Dribin has been writing professional software for over eleven years. After five years programming embedded C in the telecom industry and a brief stint riding the Internet bubble, he decided to venture out on his own. Since 2001, he has been providing independent consulting services, and in 2006, he founded Bit Maki, Inc. Find out more at http://www.bitmaki.com/ and http://www.dribin.org/dave/.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Adobe Lightroom 6.10.1 - Import, develop...
Adobe Lightroom is available as part of Adobe Creative Cloud for as little as $9.99/month bundled with Photoshop CC as part of the photography package. Lightroom 6 is also available for purchase as a... Read more
iPhoto Library Manager 4.2.7 - Manage mu...
iPhoto Library Manager allows you to organize your photos among multiple iPhoto libraries, rather than having to store all of your photos in one giant library. You can browse the photos in all your... Read more
Smultron 9.4 - Easy-to-use, powerful tex...
Smultron 9 is an elegant and powerful text editor that is easy to use. Use it to create or edit any text document. Everything from a web page, a note or a script to any single piece of text or code.... Read more
TextSoap 8.4 - Automate tedious text doc...
TextSoap can automatically remove unwanted characters, fix up messed up carriage returns, and do pretty much anything else that we can think of to text. Save time and effort. Be more productive. Stop... Read more
Merlin Project 4.2.3 - $349.00
Merlin Project is the leading professional project management software for OS X. If you plan complex projects on your Mac, you won’t get far with a simple list of tasks. Good planning raises... Read more
QuarkXPress 13.0.0.0 - Desktop publishin...
QuarkXPress 2017 is the new version that raises the bar for design and productivity. With non-destructive graphics and image editing directly within your layout, you no longer have to choose between... Read more
Path Finder 7.5 - Powerful, award-winnin...
Path Finder makes you a master of file management. Take full control over your file system. Save your time: compare and synchronize folders, view hidden files, use Dual Pane and full keyboard... Read more
Path Finder 7.5 - Powerful, award-winnin...
Path Finder makes you a master of file management. Take full control over your file system. Save your time: compare and synchronize folders, view hidden files, use Dual Pane and full keyboard... Read more
Merlin Project 4.2.3 - $349.00
Merlin Project is the leading professional project management software for OS X. If you plan complex projects on your Mac, you won’t get far with a simple list of tasks. Good planning raises... Read more
TextSoap 8.4 - Automate tedious text doc...
TextSoap can automatically remove unwanted characters, fix up messed up carriage returns, and do pretty much anything else that we can think of to text. Save time and effort. Be more productive. Stop... Read more

Latest Forum Discussions

See All

Magikarp Jump splashes onto Android worl...
If you're tired ofPokémon GObut still want something to satisfy your mobilePokémon fix,Magikarp Jumpmay just do the trick. It's out now on Android devices the world over. While it looks like a simple arcade jumper, there's quite a bit more to it... | Read more »
Purrfectly charming open-world RPG Cat Q...
Cat Quest, an expansive open-world RPG from former Koei-Tecmo developers, got a new gameplay trailer today. The video showcases the combat and exploration features of this feline-themed RPG. Cat puns abound as you travel across a large map in a... | Read more »
Jaipur: A Card Game of Duels (Games)
Jaipur: A Card Game of Duels 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: ** WARNING: iPad 2, iPad Mini 1 & iPhone 4S are NOT compatible. ** *** Special Launch Price for a limited... | Read more »
Subdivision Infinity (Games)
Subdivision Infinity 1.03 Device: iOS Universal Category: Games Price: $2.99, Version: 1.03 (iTunes) Description: Launch sale! 40% Off! Subdivision Infinity is an immersive and pulse pounding sci-fi 3D space shooter. https://www.... | Read more »
Clash of Clans' gets a huge new upd...
Clash of Clans just got a massive new update, and that's not hyperbole. The update easily tacks on a whole new game's worth of content to the hit base building game. In the update, that mysterious boat on the edge of the map has been repaired and... | Read more »
Thimbleweed Park officially headed to iO...
Welp, it's official. Thimbleweed Park will be getting a mobile version. After lots of wondering and speculation, the developers confirmed it today. Thimbleweed Park will be available on both iOS and Android sometime in the near future. There's no... | Read more »
Pokémon GO might be getting legendaries...
The long-awaited legendary Pokémon may soon be coming to Pokémon GO at long last. Data miners have already discovered that the legendary birds, Articuno, Moltres, and Zapdos are already in the game, it’s just a matter of time. [Read more] | Read more »
The best deals on the App Store this wee...
If you’ve got the Monday blues we have just the thing to cheer you up. The week is shaping up to be a spectacular one for sales. We’ve got a bunch of well-loved indie games at discounted prices this week along with a few that are a little more... | Read more »
Honor 8 Pro, a great choice for gamers
Honor is making strides to bring its brand to the forefront of mobile gaming with its latest phone, the Honor 8 Pro. The Pro sets itself apart from its predecessor, the Honor 8, with a host of premium updates that boost the device’s graphical and... | Read more »
The 4 best outdoor adventure apps
Now that we're well into the pleasant, warmer months, it's time to start making the most of the great outdoors. Spring and summer are ideal times for a bit of trekking or exploration. You don't have to go it alone, though. There are plenty of... | Read more »

Price Scanner via MacPrices.net

Sale! 15-inch 2.6GHz Silver Touch Bar MacBook...
DataVision has the 15″ 2.6GHz Silver Touch Bar MacBook Pro (MLW72LL/A) on sale for $2199 including free shipping. Their price is $200 off MSRP, and it’s the lowest price available for this model (... Read more
A Kaby Lake Processor Upgrade For The MacBook...
Now they tell me! Well, actually Apple hasn’t said anything official on the subject, but last week Bloomberg News’s Mark Gurman and Alex Webb cited unnamed “people familiar with the matter”... Read more
Kodak’s Camera-First Smartphone EKTRA Launche...
The Eastman Kodak Company and Bullitt Group have announced the availability of a U.S. GSM version of the KODAK EKTRA Smartphone. The U.S. launch coincides with a software update addressing requests... Read more
Apple Launches App Development Curriculum for...
Apple today launched a new app development curriculum designed for students who want to pursue careers in the fast-growing app economy. The curriculum is available as a free download today from Apple... Read more
Check Apple prices on any device with the iTr...
MacPrices is proud to offer readers a free iOS app (iPhones, iPads, & iPod touch) and Android app (Google Play and Amazon App Store) called iTracx, which allows you to glance at today’s lowest... Read more
9.7-inch 2017 iPad available for $298, save $...
Sams Club has 32GB 9.7″ Apple iPads available for $298 for Sams Club members. That’s $21 off MSRP. Order online and choose free local store pickup (if available) or free shipping. Read more
touchbyte Releases PhotoSync 3.2 for iOS With...
Hamburg, Germany based touchbyte has announced the release of PhotoSync 3.2 for iOS, a major upgrade to the versatile and powerful app to transfer, backup and share photos and videos over the air.... Read more
Emerson Adds Touchscreen Display and Apple Ho...
Emerson has announced the next evolution of its nationally recognized smart thermostat. The new Sensi Touch Wi-Fi Thermostat combines proven smarthome technology with a color touchscreen display and... Read more
SurfPro VPN for Mac Protects Data While Offer...
XwaveSoft has announced announce the release and immediate availability of SurfPro VPN 1.0, their secure VPN client for macOS. SurfPro VPN allows Mac users to protect their internet traffic from... Read more
13-inch Touch Bar MacBook Pros on sale for $1...
B&H Photo has 13″ MacBook Pros in stock today for up to $150 off MSRP. Shipping is free, and B&H charges NY & NJ sales tax only: - 13″ 2.9GHz/512GB Touch Bar MacBook Pro Space Gray (... Read more

Jobs Board

Data Engineer - *Apple* Media Products - Ap...
Changing the world is all in a day's work at Apple . If you love innovation, here's your chance to make a career of it. You'll work hard. But the job comes with more Read more
*Apple* Store Leader Program - Apple, Inc (U...
…Summary Learn and grow as you explore the art of leadership at the Apple Store. You'll master our retail business inside and out through training, hands-on Read more
*Apple* Integration Specialist - A3 Solution...
Apple Integration Specialist Contract-To-HireWe are searching for dedicated, well-experienced and energetic individuals for an information technology corporation Read more
Sr. Software Engineer, *Apple* Online Store...
Changing the world is all in a day's work at Apple . If you love innovation, here's your chance to make a career of it. You'll work hard. But the job comes with more Read more
Senior Engineering Project Manager, *Apple*...
Changing the world is all in a day's work at Apple . If you love innovation, here's your chance to make a career of it. You'll work hard. But the job comes with more Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.