MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for the ‘Quality Assurance’ tag

Looking Behind the Scenes of MarkUs Development

with one comment

MarkUs is entirely developed by undergraduate students. Since MarkUs is a web-application developed for and by undergraduate students, there are some challenges to overcome. Most notably there is high developer turn-around and development happens in a fairly distributed fashion.  We try to overcome those challenges by instrumenting established means of quality assurance (QA) in the open source world. In order to keep code in shape and well tested some quite heavy tooling is involved at

MarkUs website

What started as a small project at University of Toronto is becoming more and more what one might call a classical open source organization. As FOSS (Free and Open Source Software) projects don’t have a lot of money, they use various other open source software for their development. And so is MarkUs.

MarkUs developers use a mix of method and tools for their development. Some of those tools are:

  • Git (version control)
  • GitHub (wiki, issues, pull requests)
  • ReviewBoard (code review tool)
  • Tests (functional, unit)
  • Test Coverage Analysis
  • Sandbox (MarkUs demo application)
  • Blog (
  • #markus IRC channel on freenode

A subset of those tools fall into the realm of QA.

Git as Source Control Management (SCM)

Git is a decentralized SCM. Every developer has its own local repository. We have chosen a decentralized workflow. Nobody pushes directly to the central repository. Instead, people push to their own public repository hosted on GitHub (fork) and notify core developers, by instrumenting GitHub’s pull requests, to get changes in to the main MarkUs repository. This ensures that only well vetted code goes into the main development repository. What’s more, every patch has to be reviewed before being applied to the main repository (see section ReviewBoard of this blog post).

Git Workflow

GitHub as a Project Management Tool

In addition to providing public repositories, GitHub allows the team to manage issues and documentation (wiki). People can interact with the wiki using the Web interface, but also using Git. Several markup languages are supported. We chose to use the ReStructuredText syntax. The issue tracker is quite simple, but has labels rather than categories, which can come in handy in several cases. On a related note, GitHub allows for issues to be closed automatically.

GitHub also displays a graph of everyone’s forks and branches.


Before code goes into our main repository, it has to be reviewed by the team. This is an excellent way to improve code quality and to quickly spot common mistakes, especially in cases of high developer turn-around, which is the case for MarkUs. Another benefit is that it helps the whole team to keep an eye on every area of the project, even the ones they don’t code on. In other words it is an excellent tool to speed up getting familiar with the code base.

Once the code has been reviewed and/or revised, developers will check the “ship it” flag for a review request indicating that they are OK with submitting this code to the main development repository. Once the person who posted the review request received several “ship it”, the original poster can open a pull request on GitHub. After another once-over of a core developer the code in question gets merged into the main repository.

Dashboard of ReviewBoard

Unit Tests and Functional Tests

A great way to increase confidence if the code is doing what it is supposed to be doing is to write unit and/or functional tests for each piece of contributed code. We think we have been doing a quite good job at this. The number of tests increase almost on a daily bases. Functional and unit tests run every few hours and results are shown on on

Code Coverage: How Well is MarkUs’ Code Exercised When Tests Run?

Trustworthy tests are essential. We think it’s important to check how well our code is tested. Tests coverage analysis provides us with good hints as to where our code lacks testing. Ruby Coverage a.k.a. RCov is an excellent tool to provide visual feedback as to what is tested and what is not.

Test Coverage

Test Coverage

A MarkUs Demo: Sandbox

A current version of MarkUs in action is available to anybody on to play with. We try to keep the running version as up-to-date as possible. Instructions as to how to use it are described in this blog post. Note that the underlying database of this instance is flushed on a daily basis. So please don’t expect your data to persist any longer than a day or two 😉

MarkUs Blog

On our blog we describe progress, propose new features, announce new releases, post individual experiences related to MarkUs development (mostly including solutions too) and various other random things. Following our blog allows you to get a feel of the current state of the project, planned features and many more. For developers it is recommended to keep an eye on the blog every once in a while. You might find an elegant solution a problem you might have encountered. Keep reading it 🙂


#markus IRC channel

We have our IRC channel, #markus, on That’s the place where you can meet developers and can get almost instant help for a MarkUs related problem you might have. You can also just drop by and say hello. It’s a friendly small community hanging out there. In short, it is a good place to chat with current and former developers or other lurkers, who tend to hang out on IRC. See you there! 🙂

Written by Benjamin Vialle

October 16th, 2010 at 1:11 pm

Posted in Uncategorized