GHUnit: Unable to Test Target Application Classes

I've started looking into GHUnit for Unit/API testing for iOS applications, and am having difficulty using it to test an existing application's classes. I have a GHUnit test target, TestGH, which I'd like to use to test classes in my application, TestApp. I'm using Xcode 4.5 and trying to run TestGH on iPad 6.0 Simulator. I believe I've configured the TestGH build correctly in the Build Settings and Build Phases. I've set the Target Dependencies to "TestApp" I've added the *.m files for the classes I'd like to test--along with the test case classes which will test them--to the Compile Sources section TestGH. Other notable configuration: In the app target, TestApp:

Symbols Hidden By Default: No Product Name: TestApp In the test target, TestGH:

Bundle Loader: $(BUILT_PRODUCTS_DIR)/TestApp.app/TestApp Mach-O Type: Bundle Other linker flags: -ObjC, -all_load Product name: TestGH Test Host: $(BUNDLE_LOADER)

I suppose I have this mostly right, as I discovered these settings by fighting through compile/link errors, reading stackoverflow, and blogs. However, when I launch TestGH, the Log Navigator shows: error: failed to attach to process ID 2305 (2305 corresponds to 'sh' according to activity monitor, fyi) Simulator screen remains black, and Xcode shows "Attaching to TestGH" in the status. Any ideas? I've gone through many suggested fixes/workarounds I've seen discussed here related to "failed to attach to process." Deleted DerivedData folder in Library/Developer/Xcode, deleted everything under Library/Application Support/iPhone Simulator. Tried all the options under Product->Edit Scheme for the TestGH target--tried Debugger = GDB, LLDB, None, Launch = Automatically, wait. Results are always the same. I've shared this on stackoverflow, if anyone wants to comment there: http://stackoverflow.com/questions/14073252/ghunit-target-failed-to-attach-to-process

An Example of Graceful Degradation in JavaScript

In continuation of the series, this entry addresses a section in the second edition of Jeremy Keith's and Jeffrey Sambells's book "DOM Scripting: Web Design with JavaScript and the Document Object Model."
In Chapter 5 of the book, there is a syntax error under the section 'Graceful Degradation' which I have fixed below:

Example

The original text missed the closing parenthesis for the window.open call.

The authors have already addressed the error on their website, but I thought I'd write an entry to draw attention to an important topic in the book for which the above example provides an introduction.

Keith and Sambell write that, "web pages that are built using progressive enhancement will almost certainly degrade gracefully." This advocates a layered architecture with the end goal of improving usability. It is a general design principle, and in this context, refers specifically to the separation of content from presentation.

Content must be accessible to all users.

A browser's feature set should not limit the content available to the user. Rather, the content author--the web designer--must design for graceful degradation.
Take, for example, a misguided attempt to load a page in a new window:

Bad example

By setting the href attribute to "#", the web designer prohibits access to the link for users who've disabled JavaScript in their browsers. The desired result here may have been to safeguard against the default behavior for clicking a link, but the 'return false;' statement should address that. A better approach sets a valid href attribute value so the link is always accessible, even if JavaScript or popups are disabled:

Bad example

Progressive enhancement leads to graceful degradation.

Implement Your Own JavaScript getElementsByClassName method

I have started reading the second edition of Jeremy Keith's and Jeffrey Sambells's book "DOM Scripting: Web Design with JavaScript and the Document Object Model."

 In Chapter 3, under the section "Nodes -> Getting Elements", sub-section "getElementsByClassName", the author suggests implementing a custom getElementsByClassName method for JavaScript engines which do not support it natively.

 Although most current engines seem to support getElementsByClassName, the code snippet provided in the book for the custom method does not work properly. I re-wrote some of the implementation to get the desired result:

function getElementsByClassName(node, classname){
    if(node.getElementsByClassName){
        return node.getElementsByClassName(classname);
    } else { 
        var results = new Array();
        var elemsOnPage = document.getElementsByTagName("*");
        var len = elemsOnPage.length;
        var i;
        for(i = 0; i < len; i++){
            if(elemsOnPage[i].className && elemsOnPage[i].className == classname){
                results[results.length] = elemsOnPage[i];
     }
        }
        return results;
    }
}

The original code did not check if className was defined and used indexOf instead of a string comparison. Any feedback or suggestions are much appreciated and I will try to pass the information to the authors. You can buy the book here at amazon if you are interested in these topics. I highly recommend it.

What to do when bootable USB fails with "Not a COM32R image"

I was getting the message "not a COM32R image" when trying to boot from a USB flash drive created with usb-creator-kde.

I found you can work around this by typing "help" at the boot menu, and then pressing enter. Ubuntu will then boot and you can continue from there.

http://www.linuxquestions.org/questions/linux-mint-84/trying-to-boot-linux-mint-9-from-usb-flash-drive-vesamenu-c32-not-a-com32r-image-829397/

Stretching Rows in Android TableLayout

Google's Android SDK allows developers to architect a UI from the comfort and safety of XML. This is done by creating a layout resource *.xml file under the /res/layout directory of the project.

Hand-coded UIs can be difficult to maintain and update. For example, grid-based layouts can become complex and unwieldy as they evolve. An XML-based layout tries to address these problems, and the Android Developers forum provides helpful tutorials on the subject.

As I studied the layout tutorials, I hoped to use percentage values for the android:layout_height and android:layout_width attributes to evenly stretch buttons in a TableLayout. Since percentage values are not allowed however, another solution was required.

The android:stretchColumns attribute addresses part of the problem. For example, a 3-column table layout can be evenly laid out--horizontally, at least--by setting android:stretchColumns="0,1,2". But the rows are not stretched and no corresponding android:stretchRows exists.

The solution actually depends android:stretchColumns as well as a few other layout attributes and can be outlined as follows:

1. give the top-level TableLayout node in the XML file an android:weightSum value corresponding to the number of rows in the layout. If the layout has 3 rows, then set android:weightSum=3.
2. give each TableRow node within the TableLayout an android:layout_weight attribute and set the value such that the sum of all the android:layout_weight values from all the nodes within is equal to the value of android:weightSum in the containing TableLayout.
3. set the android:layout_height and android:layout_width of the items inside the TableRow elements ( in my case, a Button element ), to "fill_parent."

With this approach, I was able to achieve the above pictured layout without hard-coding any numeric values in the XML for height or width. Here is the XML that I used as a layout resource in my test Android app:

    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:weightSum="3"
    android:stretchColumns="0,1,2">

    
                android:id="@+id/pad1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="1">
 
        
                android:id="@+id/pad2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="2">
 
        
                android:id="@+id/pad3"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="3">
 

    

    
                android:id="@+id/pad4"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="4">
 
        
                android:id="@+id/pad5"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="5">
 
        
                android:id="@+id/pad6"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="6">
 
    

    
        
        
                android:id="@+id/pad8"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="8">
 
        
                android:id="@+id/pad9"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="9">
 
    

Test WebKit Rendering with Qt

Using the QtWebKit module provided by Qt, developers can test WebKit rendering without visual inspection. The QWebView class from QtWebKit, along with a few classes from QtGui, can be used to verify rendering in relatively few lines of code.

The basic approach creates a QImage by rendering a QWebView's frame to a QPainter, whose paint device is a QImage instance. Once QWebView has rendered to the QImage, this object can be simply compared with another QImage.

This is creating a screenshot of a web page and comparing it to another screenshot to confirm or refute that the images are the same. The images can be optionally saved to a file if visual proof is desired.

For example, given two QWebView objects, a screenshot for each can be generated and then compared:

QWebView viewA, viewB;
QImage screenShotA, screenShotB;
WebKitRenderTest renderTest;

screenShotA = renderTest.initWebView(QColor(Qt::red), viewA, html, QString("viewA"));

screenShotB = renderTest.initWebView(QColor(Qt::blue), viewB, html, QString("viewB"));

QString result = (screenShotA == screenShotB) ? "images are same" : "images are different";

Note that the comparison is done with the overloaded equality operator in QImage.

The WebKitRenderTest is just a helper class with little more than a function for initializing a QWebVIew, setting the HTML content, applying a background color via QWebView's QPalette, and returning a QImage--the screenshot. Here is the body of such a function:

QImage WebKitRenderTest::initWebView(QColor bgColor, QWebView& view, QString& content, QString imgName){
QPalette pal;
QBrush brush(bgColor);
brush.setStyle(Qt::SolidPattern);
pal.setBrush(QPalette::Base, brush);

view.setPalette(pal);
view.setHtml(content);
view.page()->setViewportSize(view.page()->currentFrame()->contentsSize());

QImage img(view.page()->viewportSize(), QImage::Format_ARGB32);
QPainter paintView(&img);
view.page()->currentFrame()->render(&paintView);
paintView.end();

QString imgFileName = imgName + ".png";
img.save(imgFileName); // not necessary, just for visual inspection
view.close();

return img;
}

By using the QPalette::Base color role on the brush, the entire page background can be colored as desired by the application.

The technique is straightforward and easily adapted for automated tests. It is especially suited for use with the QTestLib framework provided by Qt.

A compilable, buildable project based on this example can be found here in zipped form:
https://docs.google.com/uc?id=0B7qXaguuORTFNWM4MjE1MGMtMTg4Yi00YzQ4LTk2ZjYtYzczZjQ1NzFiOTMw&export=download&authkey=COfEpIoB&hl=en

To see how this approach is already being used in WebKit, see this Changeset:
http://trac.webkit.org/changeset/79409