Already a month has passed since the start of Google Summer of Code 2014. As previously mentioned I had developed a test case to show a failure so that we can detect it. In the past month, most of my time was spent in familiarizing and researching on the existing mochitest harness. I researched about mochitest-plain, browser-chrome and mochitest-chrome. Mochitest plain tests are normal html tests without administrator privileges while chrome tests are the ones with administrator privileges. Browser chrome tests are similar to chrome tests but they control and run the user interface(UI) of the webpage. Also, chrome tests depend on harness.xul while browser-chrome tests depend on browser-harness.xul, and browser-test-overlay.xul is used to provide an overlay to both type of tests. These files are entry points to the harness and deal with the UI of the tests.
Next, I learnt about test chunking(how the tests are segregated), manifest filtering(filtering the tests that have to be run depending on the command line options) and log parsing. It has been an interesting and a humbling experience to learn about the different things that hold together a framework. Then, I started working on Bug 992911. Mochitests till now are run per manifest and this bug basically deals with running mochitest per directory and displaying the cumulative results(passed, failed, todos) at the end. The advantage of doing this is that we can determine how many tests are run in each directory and we get a great balance between runtime and test isolation. Joel Maher had already coded the basic algorithm for this functionality but there was a problem with log parsing and summarization. On his advice, I fixed up the log parsing and we could correctly display the cumulative number of pass/fail/todo tests and I also added mach support for ‘–run-by-dir’ command. The patch is almost done and we will very soon have this functionality.
In the coming weeks, I will start working on the tool for bisecting the chunks to find the failure point of a failing test. Stay tuned!
I have been selected for Google Summer of Code 2014 and the project that I will be working on is Mochitest Failure Investigator (abstract) mentored by the awesome Joel Maher. Basically, this project aims at building a tool that will help contributors find the origin of test failures for mochitest on local as well as production machines, thus leading to accelerated development and debugging.
I am really excited for this project and will write about my work regarding the project regularly.
I have recently started contributing to Mozilla’s A-Team. I had no idea how the open source community worked and had the notion that people are too busy with their lives, so they do not entertain doubts of newcomers. But guess what? I was totally wrong. People at Mozilla are really very helpful and they in fact encourage newcomers to ask doubts.
I started contributing back in January and my first bug was a talos bug 931337. Joel Maher (jmaher) was the mentor on this bug. He is a really cool guy and he helped me set up the environment and patch up the bug. I was fascinated how things worked in Mozilla and I patched up a couple of bugs more. This included finalizing the work to support manifest in mochitest. More details about the work and its use can been seen in jmaher’s post and ahal’s post. Another interesting mochitest bug was bug 912243. At first glance, it looked like a really easy bug. But on further investigation, it turned out to be tricky and my patch failed on a number of chunks (rc1, e10s and bc) on tbpl. It took me a month to patch this bug but in retrospect I think it was good as I learned a lot about the test harness of mochitest and it taught me to become more patient. Also, I would like to thank jmaher, who continuously guided me during this time and answered every single doubt that I had. The past three months contributing at Mozilla have been awesome and I plan to continue to do so in the future as well.