Archive for April, 2015
The Behavior Driven Development (BDD) seems very logical and even optimal for applications like MarkUs. But adopting it means that all the developers should have in-depth knowledge of how testing works. It’s seems unlikely to happen due to the distributive nature of the application and the fact that many people who work on it are coming and going just like me. After spending my term on MarkUs working with RSpec I can say for sure that I’m not even close at becoming pro at testing. So forget about BDD and let’s see what I’ve done over this term.
The tickets I was working on mainly concentrated around different sorts of testing. I started with the easiest kind that involved unit testing where you test a single function to make sure it produces appropriate results using arbitrary scenarios. Sometimes it’s difficult to come up with a good scenario. You have to think about what function supposed to do and test that, but then you also have to consider wild (not too wild) possibilities that could break the function. Writing passing a test is easy, but most of the time I was only satisfied when I was able to break something that resulted in failing test and required fixing.
That happened when I began working on CSV upload functionality for Simple Grade Entry form. The upload relies on rails library parsing methods that are not ideally robust to begin with. So it’s very important that the file passes all the checks before entering the parsing stage. My wild (but not too wild) failing scenarios included checking for: presence of EOF character, appropriate EOL characters, non-CSV files that are pretending they are CSV (sneaky spies!), etc. I also discovered that any file passed through CSV upload would overwrite the original template. Even though this functionality is required for other parts of MarkUs, I thought that it could potentially cause some troubles along the way. Now this concern is handled and corresponding RSpec tests are in place.
I greatly enjoyed working with this test framework and its object-building sister – FactoryGirl. The biggest challenge I was facing is understanding of sometimes complex relationships between different MarkUs entities. And in-depth understanding is required, because there is no way to even start testing without a good idea of how different elements co-operate with each other. And then you start building factories, which have to follow the rules of multiple associations, validation and other model requirements. Testing helps a developer to get almost intimate with the code, so I believe that this term I became not just a better coder, but improved as a programmer.
A feature commonly requested by markers was the ability to annotate student submissions with LaTeX like math. This has now been implemented!
Anywhere annotations exist markers can enter LaTeX like math thanks to MathJax. When creating an annotation the marker just needs to surround the math in a pair of dollar-sign symbols. The entire annotation shown in the image above is:
should actually be $$\lt \frac 1 2$$
As would be expected, students also see LaTeX like math when viewing an annotation with math in it. This math rendering system expands (and reinforces) the utility of Markus for theory-based courses such as calculus, discrete math or linear algebra.
In addition to the MathJax integration, markers can now preview their annotation prior to submitting it.
The preview functionality will help speedup the marking process for users unfamiliar with MathJax syntax. Instead of submitting an annotation, hovering over it and then editing it, markers can now preview exactly how their annotation will look once submitted. This also allows markers to preview rich HTML annotations with bolded and italicized text.