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/.

 
AAPL
$116.47
Apple Inc.
+0.16
MSFT
$47.98
Microsoft Corpora
-0.72
GOOG
$537.50
Google Inc.
+2.67

MacTech Search:
Community Search:

Software Updates via MacUpdate

StatsBar 1.9 - Monitor system processes...
StatsBar gives you a comprehensive and detailed analysis of the following areas of your Mac: CPU usage Memory usage Disk usage Network and bandwidth usage Battery power and health (MacBooks only)... Read more
Cyberduck 4.6 - FTP and SFTP browser. (F...
Cyberduck is a robust FTP/FTP-TLS/SFTP browser for the Mac whose lack of visual clutter and cleverly intuitive features make it easy to use. Support for external editors and system technologies such... Read more
Maya 2015 - Professional 3D modeling and...
Maya is an award-winning software and powerful, integrated 3D modeling, animation, visual effects, and rendering solution. Because Maya is based on an open architecture, all your work can be scripted... Read more
Evernote 6.0.1 - Create searchable notes...
Evernote allows you to easily capture information in any environment using whatever device or platform you find most convenient, and makes this information accessible and searchable at anytime, from... Read more
calibre 2.11 - Complete e-library manage...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital... Read more
Herald 5.0.1 - Notification plugin for M...
Note: Versions 2.1.3 (for OS X 10.7), 3.0.6 (for OS X 10.8), and 4.0.8 (for OS X 10.9) are no longer supported by the developer. Herald is a notification plugin for Mail.app, Apple's Mac OS X email... Read more
Firetask 3.7 - Innovative task managemen...
Firetask uniquely combines the advantages of classical priority-and-due-date-based task management with GTD. Stay focused and on top of your commitments - Firetask's "Today" view shows all relevant... Read more
TechTool Pro 7.0.6 - Hard drive and syst...
TechTool Pro is now 7, and this is the most advanced version of the acclaimed Macintosh troubleshooting utility created in its 20-year history. Micromat has redeveloped TechTool Pro 7 to be fully 64... Read more
PhotoDesk 3.0.1 - Instagram client for p...
PhotoDesk lets you view, like, comment, and download Instagram pictures/videos! (NO Uploads! / Image Posting! Instagram forbids that! AND you *need* an *existing* Instagram account). But you can do... Read more
SuperDuper! 2.7.3 - Advanced disk clonin...
SuperDuper! is an advanced, yet easy to use disk copying program. It can, of course, make a straight copy, or "clone" -- useful when you want to move all your data from one machine to another, or do... Read more

Latest Forum Discussions

See All

Ubisoft Gives Everyone Two New Ways to E...
Ubisoft Gives Everyone Two New Ways to Earn In-Game Stuff for Far Cry 4 Posted by Jessica Fisher on November 21st, 2014 [ permalink ] | Read more »
Golfinity – Tips, Tricks, Strategies, an...
Dig this: Would you like to know what we thought of being an infinite golfer? Check out our Golfinity review! Golfinity offers unlimited ways to test your skills at golf. Here are a few ways to make sure your score doesn’t get too high and your... | Read more »
Dark Hearts, The Sequel to Haunting Meli...
Dark Hearts, The Sequel to Haunting Melissa, is Available Now Posted by Jessica Fisher on November 21st, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Meowza! Toyze Brings Talking Tom to Life...
Meowza! | Read more »
Square Enix Announces New Tactical RPG f...
Square Enix Announces New Tactical RPG for Mobile, Heavenstrike Rivals. Posted by Jessica Fisher on November 21st, 2014 [ permalink ] With their epic stories and gorgeous graphics, | Read more »
Quest for Revenge (Games)
Quest for Revenge 1.0.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.0 (iTunes) Description: The great Kingdom of the west has fallen. The gods ignore the prayers of the desperate. A dark warlord has extinguished... | Read more »
Threadz is a New Writing Adventure for Y...
Threadz is a New Writing Adventure for You and Your Friends Posted by Jessica Fisher on November 21st, 2014 [ permalink ] In the tradition of round-robin storytelling, | Read more »
SteelSeries Stratus XL Hardware Review
Made by: SteelSeries Price: $59.99 Hardware/iOS Integration Rating: 4 out of 5 stars Usability Rating: 4.5 out of 5 stars Reuse Value Rating: 4.25 out of 5 stars Build Quality Rating: 4.5 out of 5 stars Overall Rating: 4.31 out of 5 stars | Read more »
ACDSee (Photography)
ACDSee 1.0.0 Device: iOS iPhone Category: Photography Price: $1.99, Version: 1.0.0 (iTunes) Description: Capture, perfect, and share your photos with ACDSee. The ACDSee iPhone app combines an innovative camera, a powerful photo... | Read more »
ProTube for YouTube (Entertainment)
ProTube for YouTube 2.0.2 Device: iOS Universal Category: Entertainment Price: $1.99, Version: 2.0.2 (iTunes) Description: ProTube is the ultimate, fully featured YouTube app. With it's highly polished design, ProTube offers ad-free... | Read more »

Price Scanner via MacPrices.net

Save up to $400 with Apple refurbished 2014 1...
The Apple Store has restocked Apple Certified Refurbished 2014 15″ Retina MacBook Pros for up to $400 off the cost of new models. An Apple one-year warranty is included with each model, and shipping... Read more
New 13-inch 1.4GHz MacBook Air on sale for $8...
 Adorama has the 2014 13″ 1.4GHz/128GB MacBook Air on sale for $899.99 including free shipping plus NY & NJ tax only. Their price is $100 off MSRP. B&H Photo has the 13″ 1.4GHz/128GB MacBook... Read more
Apple Expected to Reverse Nine-Month Tablet S...
Apple and Samsung combined accounted for 62 percent of the nearly 36 million branded tablets shipped in 3Q 2014, according to early vendor shipment share estimates from market intelligence firm ABI... Read more
Stratos: 30 Percent of US Smartphone Owners t...
Stratos, Inc., creator of the Bluetooth Connected Card Platform, has announced results from its 2014 Holiday Mobile Payments Survey. The consumer survey found that nearly one out of three (30 percent... Read more
2014 1.4GHz Mac mini on sale for $449, save $...
 B&H Photo has lowered their price on the new 1.4GHz Mac mini to $449.99 including free shipping plus NY tax only. Their price is $50 off MSRP, and it’s the lowest price available for this new... 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
64GB iPod touch on sale for $249, save $50
Best Buy has the 64GB iPod touch on sale for $249 on their online store for a limited time. Their price is $50 off MSRP. Choose free shipping or free local store pickup (if available). Sale price for... Read more
15″ 2.2GHz Retina MacBook Pro on sale for $17...
 B&H Photo has the 2014 15″ 2.2GHz Retina MacBook Pro on sale for $1799.99 for a limited time. Shipping is free, and B&H charges NY sales tax only. B&H will also include free copies of... Read more
New Logitech AnyAngle Case/Stand Brings Flexi...
Logitec has announced the newest addition to its suite of tablet products — the Logitech AnyAngle. A protective case with an any-angle stand for iPad Air 2 and all iPad mini models, AnyAngle is the... Read more
Notebook PC Shipments Rise Year-Over-Year as...
According to preliminary results from the upcoming DisplaySearch Quarterly Mobile PC Shipment and Forecast Report, the global notebook PC market grew 10 percent year-over-year in Q3’14 to 49.4... Read more

Jobs Board

*Apple* Solutions Consultant (ASC)- Retail S...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Project Manager, *Apple* Financial Services...
**Job Summary** Apple Financial Services (AFS) offers consumers, businesses and educational institutions ways to finance Apple purchases. We work with national and Read more
*Apple* Store Leader Program - College Gradu...
Job Description: Job Summary As an Apple Store Leader Program agent, you can continue your education as you major in the art of leadership at the Apple Store. You'll Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Senior Event Manager, *Apple* Retail Market...
…This senior level position is responsible for leading and imagining the Apple Retail Team's global event strategy. Delivering an overarching brand story; in-store, Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.