Test-driven development goes hand-in-hand with any type of incremental development. Writing tests to define what you want to achieve in each iteration and then writing the code to pass them is exactly what’s needed to make regular process. As an added benefit, having the tests from previous iterations makes it easy to find out if a new feature’s implementation breaks existing functionality.

For unit testing in PHP, the natural choice in PHPUnit. At first, I had some difficulty getting PHPUnit set up from the installation instructions, but adding a sudo to the beginning of each instruction solved all my problems.

At the very basic level, I want my application to be able to take in a string which is the hex representation of a MIPS machine code instruction and output the instruction in assembly code. I’d like to accomplish this in a class structure, and knowing that the machine code for add $t1, $t2, $t0 is 0×01484820, the first test verifies that this is the result my code gives.

public function testGetAssemblyCodeAdd() {
    $input = '01484820';
    $expected = 'add $t1, $t2, $t0';
    $temp = new MipsInstruction($input);
    $this->assertEquals($expected, $temp->getAssemblyCode());
}

The easiest way to code this to make it work is to hardcode the output:

class MipsInstruction {
    public function __construct($machineCode) {
        // does nothing
    }

    public function getAssemblyCode() {
        return 'add $t1, $t2, $t0';
    }
}

Running phpunit on the one test now results in OK (1 test, 1 assertion), whoo! A commit is in order for this. Unfortunately, the code doesn’t do anything other than pass this one test, so the next step is to add a couple more tests:

public function testGetAssemblyCodeSub() {
    $input = '01484822';
    $expected = 'sub $t1, $t2, $t0';
    $temp = new MipsInstruction($input);
    $this->assertEquals($expected, $temp->getAssemblyCode());
}

public function testGetAssemblyCodeOr() {
    $input = '01484825';
    $expected = 'or $t1, $t2, $t0';
    $temp = new MipsInstruction($input);
    $this->assertEquals($expected, $temp->getAssemblyCode());
}

resulting in:

FAILURES!
Tests: 3, Assertions: 3, Failures: 2

Once again, I’m making these pass the easy way first and can improve the code later once I know it works.

class MipsInstruction {
    private $inst;

    public function __construct($machineCode) {
        $this->inst = substr($machineCode, -1);
    }

    public function getAssemblyCode() {
        switch ($this->inst) {
            case '0':
                return 'add $t1, $t2, $t0';
            case '2':
                return 'sub $t1, $t2, $t0';
            case '5':
                return 'or $t1, $t2, $t0';
        }
    }
}

Now that all tests pass, it’s time to commit and I’m ready to start refactoring.

Step one: Come up with an idea

This was a project I was interested in doing while studying for Computer Architecture. It’s a simple web application that takes a MIPS instruction in machine code and then displays it in assembly code with details on the conversion. Honestly, the idea originated a semester earlier while learning the LC-3 toy language, and expanding the project to handle multiple languages is a possible future enhancement.

Step Two: Come up with a plan

The main reason I never really got started on this project before is because I always started with the architecture. I drew out diagrams of class hierarchies and debated the pros and cons of every possible design decision but never got to the coding part. To avoid this problem, this time I’m going with a pure incremental development approach and only a general overview of the desired end product.

As far as a technology stack, I’m using PHP mainly as a language refresher along with Git for my repository.

Step 3: Set up a repository

Subversion is my tried-and-true, so this is an opportunity to try another popular version control system that’s new to me. Fortunately, git has super easy set-up and hosting on github is free for open-source projects.

As everything is flif to me, you can find this project under the name Flif Risc. For now, it’s just an almost empty README, but it’s a start for things to come.

I had a class in middle school where we did a little bit of programming. I don’t remember much about it, and the programs we wrote probably weren’t more than 25 lines. The one thing I do remember is that we used gotos. No object-oriented programming, not even functional programming.

The reason I mention this now is that I was talking one of my colleagues today, arguing PHP’s case, as he supported Python, and I mentioned that as of PHP 5.3, PHP now has a goto operator. He was really hoping that was a joke, and now probably takes the language significantly less seriously.

There are plenty of criticisms of goto, not the least important of which is Edsger Dijkstra’s Go To Statement Considered Harmful. The crux of most arguments, though, seems to be that goto statements are not inherently semantic and as such aren’t appropriate for modern structured languages.

I’m not using PHP 5.3 yet, so I can’t say that I’ve used goto already, but I don’t see why having a goto operator can make a language intrinsicly bad. There’s some code that looks gacky however you try to write it, and in some cases a simple goto may actually make it easier to read and understand, even if it also has its share of bad uses.

Looking over some comments on goto use, one of the concerns I find most interesting is that of the kitchen sink mentality. Personally, I enjoy PHP because I can have one language and use it for procedural, functional, or object-oriented code–whatever I feel is most appropriate at the time. But, yes, this can also lead to poor coding standards and huge misunderstandings between, say two developers who are both writing code in PHP but with two completely different programming paradigms.

How well a language like this works for you depends on how you use it, and I think I can use it effectively, but if others prefer to work with just one subset at a time–that’s totally fine too. Anyhow, I plan to take a look this summer at this awe-inspiring Python that everyone around me keeps evangelizing (except for Jared, who loves Rails), so who knows? Maybe I’ll be enlightened then.

For the most part, I followed affacat’s instructions on his successful convert from SMF to bbPress, trying it out first on my own machine of course before ready to go live:

1. Install bbPress 0.9.0.4 and WordPress 2.7.1. I chose to put bbPress in a subdirectory of WordPress. Set up the database integration as part of the bbPress installation and delete any posts created on install.
2. Install the latest phpBB with the necessary converter to move my existing members and posts to bbPress.
3. Install Jaim’s phpBB to bbPress converter. I had to change bb_users to wp_users, and delete the first user and forum from the SQL because there are already a first user and forum in bbPress. I’m not sure what the topic_resolved key was from, so I removed that option. Then I copied and pasted the code from bbPress into this tool to generate my topic and username slugs. (There may have been other changes also that I didn’t keep track of.)
4. Finally, I imported the SQL into my database.
5. Install and activate SuperAnn’s WordPress plugin for WordPress / bbPress cookie integration.
6. Activate other plugins.
7. Post the first blog entry and new forum thread to announce the updates.

Man, it feels good to finally have the base I need to build up my site.