Add unit tests for api-tools/parser/gradeLoader and api-tools/parser/profileLoader

[jpahm]

Add unit tests using Go's built-in testing library. I would personally be in favor of the test files being within the same package as the files being tested so that non-exported methods can be tested more easily; make sure to follow the _test.go file naming convention detailed in the linked docs. Be sure to seek out resources for details on how to write good unit tests if you are unsure.

[SoggyRhino]

Can I take this

[jpahm]

Can I take this

All yours!

[SoggyRhino]

I've been pretty busy so I only just started on this but I had a couple of questions, they're mostly pedantic though.

I have 2 utility functions (unmarshellFile and copyDirectory) is it fine to move them to the utils/methods.go? They are currently only used in the tests but it feels slightly cleaner for them to go there.

I noticed that main.go panics when some flags are missing, I feel like we should just exit the program.

Currently my solution bypasses this bug but grade loader expects the log dir to be log/ but the log dir is specified by flag.

[jpahm]

I have 2 utility functions (unmarshellFile and copyDirectory) is it fine to move them to the utils/methods.go? They are currently only used in the tests but it feels slightly cleaner for them to go there.

That's fine -- just make sure it's spelled unmarshalFile :)

I noticed that main.go panics when some flags are missing, I feel like we should just exit the program.

Could you elaborate as to what this would change?

Currently my solution bypasses this bug but grade loader expects the log dir to be log/ but the log dir is specified by flag.

Good catch -- it would be great if you could update the grade loader to pull from the actual set log dir instead of it being hardcoded to /log/!

[SoggyRhino]

Could you elaborate as to what this would change?

In the switch statement in main(), where we handle command-line flags, there are a couple cases that use log.Panic. I’d suggest using log.Fatal instead.

I think it makes more sense to close the program gracefully as missing flags is not really a programmatic error its just an invalid user input. This shouldn't cause the program to go into an unrecoverable state, it should just exit. Also the stack trace clutters the terminal and doesn't provide any value.

These are the 2 instances where we panic.

log.Panic("No term specified for coursebook scraping! Use -term to specify.")
log.Panic("You must specify which type of scraping you would like to perform with one of the scraping flags!")

Current ouput for .\api-tools.exe -scrape -coursebook

01:00:55 No term specified for coursebook scraping! Use -term to specify.
panic: No term specified for coursebook scraping! Use -term to specify.

goroutine 1 [running]:
log.Panic({0xc0001cfec8?, 0xef72c0?, 0xc000008ac8?})
	C:/Users/Ian/go/go1.23.4/src/log/log.go:432 +0x5a
main.main()
	C:/Users/Ian/GolandProjects/api-tools/main.go:101 +0x87a

[jpahm]

Also the stack trace clutters the terminal and doesn't provide any value.

I'd say this alone is a solid reason -- feel free to use log.Fatal instead :)

[mikehquan19]

closes by #148