TDD Practice in Brave

For this lab, we’d like to practice the TDD (Test Driven Development) on Brave URL bug.  Essentially, TDD is the process of test-first development, making our code passing the test we just created.

After you start your brave build, heading to the URL bar and input

https://www.google.ca/search?q=dog cat

enter (space in between), you will notice the different result compared with the behavior in Chrome for example.

It turns out Brave doesn’t take care of the spacing in the query string. Instead of returning a search string with “dog%20cat”, we actually got 2 separate string “dog” and “cat”.

Once we have our desired result, we can now add our test case for this specific behavior in test/unit/lib/urlutilTest.js

Note the urlUtil inside the assert statement, it gives us hint where the code might sit. So heading to the js/lib/urlutil.js, navigate to isNotURL function, let’s make changes right before the UrlUtil.getScheme(str)

By issuing npm run test -- --grep="urlutil", our test should pass and also the bug should be fixed now

Learn from the Code Infrastructure

For the last release, I was looking into the Mozilla GitHub repo and hoping to find some bugs to fix. Since most projects in Mozilla are split into small components, therefore, there are relatively a lot more miscellaneous bugs compared to the centralized VSCode and Brave project repo.

As for my growth goals, I want to take this chance to learn from the infrastructure and development cycle of the open source project.

---

The first bug I was working on is to add CSS lint support to the Blurts Server‘s infrastructure. Blurts Server is a node.js prototyping project for Mozilla Breach Alert feature. The fixing went straightforward since the issue page already gives out the solution. All I need is to read through the stylelint repo and understand the basic usage and apply it to the project.

Basically, the package.json is the core when working with node.js, since we not only use it to include dependencies but to define behaviors. Not surprisingly, many of the js libraries are able to work together, which makes the infrastructure changes a lot easier without extra modification.

For example, we just need to insert line #7 in the “scripts” section to enable “npm run lint” command to trigger our stylelint check. And we could customize our CSS checking rules by simply adding the “.stylelintrc” file.

	{
	"dependencies": {
	},
	"scripts": {
	"lint": "npm-run-all lint:*",
	"lint:js": "eslint .",
	"lint:css": "stylelint –fix 'public/css/**/*.css'",
	"lint:nsp": "nsp check",
	"pretest": "npm run lint"
	}
	}

view raw

package.json

hosted with ❤ by GitHub

---

The second one is to remove unused references from the Kitsune, which is a Django application. I haven’t done any Python before, but I didn’t find it so hard to perform a clean-up.

By running the “git grep” command with -il options, I can easily identify where the references are used.

$ git grep -il 'treejack'
kitsune/products/jinja2/products/product.html
kitsune/sumo/migrations/0002_initial_data.py

What really interests me is the “product.html“, unlike normal HTML, they use {%...%} as open/close tag. After research, I figured out the “jinja” in the file path is actually a template engine for Python. And the {%...%} blocks represent the control structures, for instance, for loop and if…else statement.

---

The last issue I encountered is similar to the second one – do a bit of clean-up, while the topic is about logging in JavaScript.

What I have learned:

As part of the development, a project may need to utilize a various set of tools and libraries to fulfill testing purposes or doing some proofs-of-concept, but as the project progresses, constant monitoring and code maintenance is inevitable.

Learning how to set up and categorize the infrastructure is as important as implementing new features since it certainly provides convenience to maintain code health and adding further supports.