Test-driven development is a popular method of writing software. The idea is that you write tests for your code first, then you write the code that gets the tests to pass. We're going to approach this project using a bit of TDD.
We need a function that accepts a URL string as input and returns a "normalized" URL. To "normalize" means to "make the same". For example, all of these URLs are the "same page" according to most websites and HTTP standards:
https://blog.boot.dev/path/https://blog.boot.dev/pathhttp://blog.boot.dev/path/http://blog.boot.dev/pathWe want our normalizeURL() function to map all of those same inputs to a single normalized output: blog.boot.dev/path.
Keep in mind the normalized URL isn't going to be used to make requests, it's just going to be used to compare URLs to see if they are the same page.
In test-driven development (TDD), we typically follow this flow:
If you'd like, you can read up on the standard library's testing package and this example of a unit test before you start.
The go test command will looks for and runs functions that end in _test.go,
func TestNormalizeURL(t *testing.T) {
tests := []struct {
name string
inputURL string
expected string
}{
{
name: "remove scheme",
inputURL: "https://blog.boot.dev/path",
expected: "blog.boot.dev/path",
},
// add more test cases here
}
for i, tc := range tests {
t.Run(tc.name, func(t *testing.T) {
actual, err := normalizeURL(tc.inputURL)
if err != nil {
t.Errorf("Test %v - '%s' FAIL: unexpected error: %v", i, tc.name, err)
return
}
if actual != tc.expected {
t.Errorf("Test %v - %s FAIL: expected URL: %v, actual: %v", i, tc.name, tc.expected, actual)
}
})
}
}
Try to test all the edge-cases you can think of.
You should see some failing tests now, which is expected because you haven't filled in the normalizeURL function yet.
Run and submit the CLI tests from the root of the module.