DEV Community: Adil 🧩

Gopher Gym - Gopher Quiz 2 - TDD!

Adil 🧩 — Mon, 03 Jun 2019 06:15:29 +0000

2 Jun 2019 at 01:52

We finished the last post with three tasks to tackle:

Adding tests
Keeping track of the score
Adding a flag that allows the CSV file to be customised.

The priority is to add tests, as I’m a firm believer in the benefits of Test Driven Development, often abbreviated as TDD. In a nutshell, you write a test of some behaviour you want to implement. You then run the test, see it fail, and make the smallest possible change to make it pass. Once your test is green, it’s time to refactor. Thus it becomes a cycle; red, green, refactor.

It helps you avoid a lot of common pitfalls when it comes to coding, as well as forcing you to think about your code and domain more abstractly.

Go has a testing package from the standard library, so let’s have a try at writing a unit test (a unit test is a test that tests a small ‘unit’ of code). Let’s pick a small bit of code that performs a single function, and write a test for it. In cases you forgot what the code looks like at the moment, here’s the entire thing

package main

import (
    "bufio"
    "encoding/csv"
    "fmt"
    "log"
    "os"
    "strings"
)

type quizItem struct {
    question string
    answer   string
}

func main() {
    csvFile, err := os.Open("problems.csv")
    if err != nil {
        log.Fatal(err)
    }
    defer csvFile.Close()

    reader := csv.NewReader(csvFile)
    records, err := reader.ReadAll()

    if err != nil {
        log.Fatal(err)
    }

    for i := 0; i < len(records); i++ {
        // Create quizItem object
        quizItem := quizItem{records[i][0], records[i][1]}
        // Print out the question
        fmt.Println("Question:", quizItem.question)
        // Create reader and allow user to input their answer
        reader := bufio.NewReader(os.Stdin)
        fmt.Print("Enter your answer now: ")
        // Expect answer to be given once they hit return
        text, _ := reader.ReadString('\n')
        fmt.Println("Your answer is:", text)
        // Trim the newline suffix from the input
        text = strings.TrimSuffix(text, "\n")
        if text == quizItem.answer {
            fmt.Println("Correct! Well done")
        } else {
            fmt.Println("WRONG! Answer is:", quizItem.answer)
        }
    }

}

Let’s recap on what the main function is doing.

It reads a CSV file and loads it into memory until the main function finishes executing (defer is a keyword that allows you to run some code at the end of a function’s execution)
It instantiates a CSV reader, and uses reader.ReadAll() to create a slice of slices composed of strings (the successful return value type for ReadAll is [][]string which translates to 2 dimensional array where all elements in the inner slices are strings.
We create a for loop which will iterate through each of the inner slices in the outermost slice (inner slice being a line in the CSV, and the outermost slice being all of the CSV lines.
We create instantiate a quizItem struct from the information contained in the inner slice.
We print the question from the quizItem struct, and print an instruction to the user.
We instantiate a bufio reader to take the input from stdin until it receives a /n keypress.
We print the user’s answer, and then use TrimSuffix to remove the invisible /n character from the user’s answer.
Finally, we compare the two, and print a message to the user, which has different content depending on whether they got the answer right or wrong.

Point 8 is something that I would like to test; so let’s imagine what the code would look like in an ideal world. I want it to take two arguments, both of type string, and I want it to return a string too. I want the return value to be determined by the arguments that are passed in, specifically if they match or not.

3 Jun 2019 at 04:05

Chrono Trigger: Main Theme, a song by London Philharmonic Orchestra on Spotify

Let’s write a test in Go! There are three steps here

Creating a function which tests the unit of code in question. The test function should have the format function TestXxx(*testing.T) where Xxx does not start with a lowercase letter. (The asterisk is a pointer to the location of the testing variable in memory)
Creating a file whose name ends in _test.go, and placing our test inside the file.
Run go test and see blood (hopefully)!

It’s quite simple isn’t it? Let’s get started.
$ touch main_test.go to create the test file in our local directory, which now contains 4 files;

— GopherQuiz The binary executable we compiled with go build
— main.go The file containing our code
— main_test.go Our newly created test file
— problems.csv The CSV file containing our quiz

For the time being, we will keep it like this, but it’s important to recognise that as a project grows, organising your files is extremely important. It helps others find what they are looking for faster, while also providing context to the code. pool/write.go is easy to recognise as a file related writing to a pool, while channel/write.go would be relating to writing to a channel.

Tangent over, let’s go back to writing our test in main_test.go

package main

import “testing”

func TestCompareAnswer(t *testing.T) {
  got := CompareAnswer(“3”, “3”)
  if got != true {
  t.Errorf(“CompareAnswer = %v; want true”, got)
 }
}

First we specify the package we are testing, which in this case is main. We import the testing package so that we can use it (remember the format of the test function requires t *testing.T as an argument. Then we define our test.

Now I’m going to go on a small tangent about Test Driven Development (TDD). When doing TDD, you always write a test first, before ANY other code. What does this mean? It means that before you think about how to do something, you think about what you want to do.

I want to compare two strings and see if they match, and return a different string depending on whether they match or not. So I will call my test CompareAnswer. But is it just comparing the answers? No, it’s also returning either a success or a failure message depending on the comparison. So (without going into the rabbit hole of naming stuff), I’m going to change the name of the test to CheckAnswer.

func TestCheckAnswer(t *testing.T) {
  got := CheckAnswer(“3”, “3”)
  if got != true {
    t.Errorf(“CheckAnswer = %v; want true”, got)
  }
}

Going back to the code; we then set the output of the function we are testing CheckAnswer to a variable called got. Incase you forgot, := is shorthand for declaring a variable with implicit type. We then make our assertion: is what we got true? If is is, fail the test using t.ErrorF (prints an error with formatting), in which we let the user know what they got, and what we expected. The test passes if it executes without failure. (FYI, ErrorF is simply LogF followed by Fail. Had we wished to fail the test without giving a message, we could’ve just used Fail.)

Pretty simple right? No-clickbait, but this one simple trick will save you hours and hours of development time; a good test suite is the difference between hating and loving your job when things go tits up and you need to apply a patch.

I left my first job because of the stress incurred from working on production web applications with zero tests; nothing is more frightening then having to change code and not knowing if you’re about to break something else.

Right, back to the test. It’s actually a bad test right now because although it’s named correctly, the assertion is wrong. Let’s think back; what do we want this code to do? We want it to compare two strings, and return one string if they match, and a different string if they do not. Let’s make those changes, to the sweet sounds of the best video game OST ever Secret of the Forest.

func TestCheckAnswer(t *testing.T) {
  gotCorrect := CheckAnswer(“3”, “3”)
  if gotCorrect != “Correct! Well done” {
    t.Errorf(“CheckAnswer = %v; want ‘Correct! Well Done’”, gotCorrect)
  }
  gotIncorrect := CheckAnswer(“3”, “2”)
  if gotIncorrect != “WRONG! Answer is: 2” {
    t.Errorf(“CheckAnswer = %v; want ‘WRONG! Answer is: 2’”, gotIncorrect)
  }
}

Right, let’s go through this step by step; we assign the return of the function we are testing to gotCorrect, compare it to the string we expect to receive, and fail if we do not receive what we expect. We then do the same thing with an answer which is incorrect, repeat the process. Nice!

But there’s a slight issue here; something that is seemingly innocuous and innocent. Something that can quite easily make a test suite, your shield and sword against bugs, heavy and unwieldy, quickly becoming a burden that will make your fellow developers curse and can put off inexperienced developers writing tests at all.

Recall the reason we began writing this test; we wanted to take a unit of our code and test that it works independently. If it works by itself, it stands to reason that if the program isn’t working, the fault lies with another part of the program. By making small, modular units of code, we can test each part independently, and thus the surface area where bugs can hide becomes smaller. This concept of small, modular units of code that do one thing independently of all else is often referred to as the Single Responsibility Principle (SRP).

Our test violates the SRP; it has two responsibilities. An easy way to check if your code violates SRP is to ask it questions about what it does.

ME: What’s cracking TestCheckAnswer, how’s it hanging? You up too much these days?

TestCheckAnswer: Shiiiiiiiiiiiiiiiet, they got me on some slave-type shit bro.

ME: What you mean man? I thought you were just checking answers, that’s what you do right?

TestCheckAnswer: Dude, look at my fricking name, I’m TestCheckAnswer, but for some reason I have to check two answers. What happens when I wanna go on holiday? Y’all ain’t gonna have no one testing CheckAnswer! In fact, I don’t even wanna be called TestCheckAnswer, I wanna be called TestCheckCorrectAnswer so I don’t have to be here doing the work of two people! Do me a solid and change that ASAP, cause CheckAnswer might start getting more work to do, and then y’all are gonna have me doing more work, and ergo you are gonna have to do more work! Come on bro work with me here, I ain’t trying to end up like main, that dude got so many problems I don’t even know how he’s still around!

(I always end up personifying my tests based on a good friend of mine who’s pretty lazy. Naturally, he’s a great programmer!)

Tests are functions, functions should have a single responsibility, ergo, we should change this test to have a single responsibility. We do that by splitting them out, which in this case is pretty simple;

package main

import “testing”

func TestCheckCorrectAnswer(t *testing.T) {
  got := CheckAnswer(“3”, “3”)
  if got != “Correct! Well done” {
    t.Errorf(“CheckCorrectAnswer = %v; want ‘Correct! Well Done’”, got)
  }
}

func TestCheckIncorrectAnswer(t *testing.T) {
  got := CheckAnswer(“3”, “2”)
  if got != “WRONG! Answer is: 2” {
    t.Errorf(“CheckIncorrectAnswer = %v; want ‘WRONG! Answer is: 2’”, got)
  }
}

The benefit of this is that it makes our code more flexible; flexible code is good because the future is uncertain, and in the face of uncertainty, we must be able to adapt to new conditions quickly.

Right! We’ve got our test, now what? We run it, and watch it fail!

06:24 $ go test
# github.com/adilw3nomad/GopherQuiz [github.com/adilw3nomad/GopherQuiz.test]
./main_test.go:6:9: undefined: CheckAnswer
./main_test.go:13:9: undefined: CheckAnswer
FAIL    github.com/adilw3nomad/GopherQuiz [build failed]

Now is the fun part. We write the bare minimum, simplest code to make the error message change. Imagine the test error output as your hint guide; it tells us CheckAnswer is undefined, so let’s define it!

func CheckAnswer() {
}

That’s it! We make the smallest change possible to satisfy the error we received. Now we run the test again.

06:29 $ go test
# github.com/adilw3nomad/GopherQuiz [github.com/adilw3nomad/GopherQuiz.test]
./main_test.go:6:20: too many arguments in call to CheckAnswer
        have (string, string)
        want ()
./main_test.go:6:20: CheckAnswer("3", "3") used as value
./main_test.go:13:20: too many arguments in call to CheckAnswer
        have (string, string)
        want ()
./main_test.go:13:20: CheckAnswer("3", "2") used as value
FAIL    github.com/adilw3nomad/GopherQuiz [build failed]

Success! We have got a different error message. A different error message from a test is always a good thing; it means that you are making progress. This one is a little different; it is telling us that TestCheckCorrectAnswer is sending too many arguments to CheckAnswer. It even helps us more by telling us what we have given it have (string, string), and what it wants want ().

Remember, we want to satisfy the test. So if the test has two strings to pass, we must make CheckAnswer accept two strings.

func CheckAnswer(string, string) {
  return
}

Running the test again gives us a more peculiar output;

06:35 $ go test
# github.com/adilw3nomad/GopherQuiz [github.com/adilw3nomad/GopherQuiz.test]
./main_test.go:6:20: CheckAnswer("3", "3") used as value
./main_test.go:13:20: CheckAnswer("3", "2") used as value
FAIL    github.com/adilw3nomad/GopherQuiz [build failed]

This error message is a bit different, but still useful none the less! It tells us that the function call we made is used as a value. What does this mean?

If you have a look at the CheckAnswer function above, you can see that we don’t specify a return type. This means the function itself is returned. This is pretty cool, I wonder if it means you could create functions that return other functions?

Anyways, to fix this, we add a return value.

func CheckAnswer(string, string) int {
  return 1
}

06:36 $ go test
# github.com/adilw3nomad/GopherQuiz [github.com/adilw3nomad/GopherQuiz.test]
./main_test.go:7:9: cannot convert "Correct! Well done" (type untyped string) to type int
./main_test.go:7:9: invalid operation: got != "Correct! Well done" (mismatched types int and string)
./main_test.go:14:9: cannot convert "WRONG! Answer is: 2" (type untyped string) to type int
./main_test.go:14:9: invalid operation: got != "WRONG! Answer is: 2" (mismatched types int and string)
FAIL    github.com/adilw3nomad/GopherQuiz [build failed]

I used int to show you that, although we know what our function will do (since we spiked it), there’s a lot of scenarios where you have no idea where to begin. In these scenarios, the best thing to do is to make a hypothesis, and run the test to see what happens. In this case, it’s an easy fix.

func CheckAnswer(string, string) string {
  return ""
}

06:47 $ go test
--- FAIL: TestCheckCorrectAnswer (0.00s)
    main_test.go:8: CheckCorrectAnswer = ; want 'Correct! Well Done'
--- FAIL: TestCheckIncorrectAnswer (0.00s)
    main_test.go:15: CheckIncorrectAnswer = ; want 'WRONG! Answer is: 2'
FAIL
exit status 1
FAIL    github.com/adilw3nomad/GopherQuiz       0.005s

We’re getting closer! Let’s do the simplest thing possible to make one of the tests pass.

func CheckAnswer(string, string) string {
  return "Correct! Well done"
}

06:51 $ go test
--- FAIL: TestCheckIncorrectAnswer (0.00s)
    main_test.go:15: CheckIncorrectAnswer = Correct! Well done; want 'WRONG! Answer is: 2'
FAIL
exit status 1
FAIL    github.com/adilw3nomad/GopherQuiz       0.005s

Finally! A passing test! But we’re not done yet, because one of the other tests is still failing. But this is the essence of TDD; you write small changes incrementally, and run your tests each time you go along.

When you hit an error message, you make a hypothesis as to it’s cause, make the relevant change to your code, and test it by…. Running the tests! In this way, you are protected from adding needless code that isn’t used.

I’m going to skip ahead now and show you the final CheckAnswer function.

func CheckAnswer(answer string, correctAnswer string) string {
  if answer == correctAnswer {
    return “Correct! Well done”
  } else {
    return (“WRONG! Answer is: “ + correctAnswer)
  }
}

06:56 $ go test
PASS
ok      github.com/adilw3nomad/GopherQuiz       0.004s

And there we have it! No more failing tests!

I hope you’ve enjoyed this blog post and found it informative, and as always, C&C is encouraged and appreciated. I’m going to leave it here since it’s gotten quite long, but in the next blog post we’ll continue the task by.

Adding a customisable timer
Implementing score
Allow custom quiz’s to be pass by file name

Implementing a 'radio button' in Golang shell program

Adil 🧩 — Sun, 02 Jun 2019 09:27:49 +0000

I came across this question in the Gopher slack channel and I thought I might have a crack at answering it. Gopher newbie, so as always C&C welcome and appreciated!

@J so you want to prompt with a question first. The code for this is pretty simple;

reader := bufio.NewReader(os.Stdin)
fmt.Print("? How would you like to use ESLint??")

Now the next part is a bit ambigious, because while you mention radio button like behaviour, the screen shot you supplied is actually a selector that you navigate by using the directional keys. If it were an actual radio button, you could simply attach a value to each of the options, and then execute the code you want depending on the answer. For example

? How would you like to use ESLint?
> To check syntax only (1)
> To check syntax and find problems (2)
> To check syntax, find problems, and  enforce code style (3)
$ > 3
! You have selected the syntax only mode

To implement this would be pretty simple too.

reader := bufio.NewReader(os.Stdin)
fmt.Print("? How would you like to use ESLint??")
fmt.Print("To check syntax only (1) ")
fmt.Print("To check syntax and find problems (2) ")
fmt.Print("To check syntax, find problems, and enforce code style (3) ")

answer, _ := reader.ReadString('\n') // Allow user input up until and including \n
answer = strings.TrimSuffix(answer, "\n") // Remove trailing \n from string
if answer == "1" {
  // check syntax code execution
} else if answer == "2" {
  // check syntax and find problems code execution
} else if answer == "3" {
  // check syntax find problems and enfore style code code execution
} else {
  fmt.Print("Answer isn't recognised")
  // start again
}

I would probably use a switch statement to make it a little more cleaner too, and also wrap the question printing and answer gathering into a function that would be called when the answer isn't recognized. but then again, there's quite a bit of refactoring that you could do.

If you wish to implement the selector behaviour, where you can navigate the options with the directional keys, it would be more complex (I'd imagine). You'd have to find a way to;

Print multiple lines that can be navigated
Allow user to navigate the lines (probably by using the same method as above, but triggering navigation when the arrow keys are pressed)
Highlight the line currently being selected
Run behaviour based on selected option when the enter key is pressed.

Personally, I feel like that's a lot of work for not much gain in UX, but it definitely is possible in Go, as are all things if you put your mind to it!

Gopher Gym: Quiz Game - Part 1

Adil 🧩 — Sun, 02 Jun 2019 01:02:12 +0000

29 May 2019 at 05:20

I started my morning with some cowboy coffee; which is coffee brewed in a saucepan, since I seem to have misplaced my aero press, as I listened to Go for beginners, and discovered Gophercises, a set of coding exercises in Go aimed at people who’ve done a few tutorials but have kinda lost steam. I felt like that described me, so I’ve decided to tackle these exercises while journalling my progress and learning in this blog.

/I have a peculiar writing style because I write in tandem with coding, so there’s a lot of tense switching, so apologies in advance. All comments and criticisms are encouraged, no matter how harsh or abrasive, as long as they are constructive!/

I’m going to tackle the first challenge, GitHub - gophercises/quiz: Ex 1 - Run timed quizzes via the command line.

So the first thing I need to do is make a new go project. I create a new repository on github, clone it into my $GOPATH/src/github.com/adilw3nomad, and made a simple main.go file that prints Hello! when it’s run.

I run go build && ./GopherQuiz, which compiles my program into a binary called GopherQuiz and runs said file. Hello! was printed to the command line. Success! I now have something to work with.

Lets go over the exercise details; I’m going to make the points which I feel are important to the domain in bold.

Create a program that will read in a quiz provided via a CSV file (more details below) and will then give the quiz to a user keeping track of how many questions they get right and how many they get incorrect. Regardless of whether the answer is correct or wrong the next question should be asked immediately afterwards.
The CSV file should default to problems.csv (example shown below), but the user should be able to customize the filename via a flag.

I like to break down stuff like this into bullet points;

There’s a quiz, which has questions.
Questions can be either right or wrong, ergo they have an answer.
There’s a score, or at least a concept of a score
The quiz is created from a CSV file with questions and answers

That’s the domain of the application; now let’s have a think about the behaviour. The application has a single dependency; it requires a CSV file to create the quiz. Without a CSV file, there is no quiz, and the app is useless. So the first thing we need to do is get our app to load and read a CSV file. I won’t worry about the filename flag just yet, or even the content of the CSV. All I want to focus on is loading and reading a CSV file into the application.

Create array/slice to hold quiz items. (Question, Answer)
Read each line of the CSV and create a quiz item from it.
Iterate through the slice, printing the question to stdout
Accept an answer from the user
If answer matches the user’s input, increase score counter by one.

I’m going to do this in the worst way possible; with no tests, all in the main function. Then I’ll write some tests for it, and then I’ll refactor, knowing that my coce still works thanks to the tests.

31 May 2019 at 06:36

func main() {
  csvFile, err := os.Open(“problems.csv”)
  if err != nil {
    log.Fatal(err)
  }
  defer csvFile.Close()

  reader := csv.NewReader(csvFile)
  records, err := reader.ReadAll()

  if err != nil {
    log.Fatal(err)
  }

  for i := 0; i < len(records); i++ {
    fmt.Println("Question: ", records[i][0])
    fmt.Println("Answer: ", records[i][1])
  }
}

So this is what I have so far; I open the file using the os package, and do not close it until the program stops running. I then create a 2 dimensional array of each of the CSV elements using csv.Reader.ReadAll. Finally, to see what I’m working with, I loop through the records and print each one. protip; PrintLn is useful for just printing out whatever as long as it’s printable.

So I now have my CSV input, what do I want to do with it? I want to

Ask each question
Accept an user’s answer
Compare it to the correct answer
Increase a counter if they are the same.

What does it mean to ask a question in a command line app? It means writing to stdout. What does it mean to accept an answer? Reading from stdin. I’ve already got writing to stdout covered by using PrintLn, and in order to read from stdin, I’m going to use the bufio package.

// omitted unchanged code for brevity
for I := 0; I < len(records); I++ {
  // Print the question out
  fmt.Println(“Question: “, records[I][0])
  // Read from stdin for answer
  reader := bufio.NewReader(os.Stdin)
  fmt.Print(“Enter your answer now: “)
  // Expect answer to be given once they hit return
  text, _ := reader.ReadString(‘\n’)

  if text == records[I][1] {
    fmt.Println(“Correct!”)
  } else {
    fmt.Println(“WRONG! Answer is: “, records[I][1])
  }
}

What we’ve done here is loop through the lines of the CSV, print the question out, then instantiate a new buffered I/O reader which uses the os.Stdin interface. Next we print an instruction to the user, and use the reader.ReadString method to read their input. The parameter passed to ReadString is the delimiter that lets the reader know when to stop reading. Then a simple conditional statement checks to see if the answer is correct.

Pretty sweet, except it doesn’t work! I suspect it’s because I am not making the assertion correctly. Let’s do some debugging!. But first, I’m going to take a break and play a game of Autochess :D

31 May 2019 at 08:22

A game of autochess (and some laundry time) later, I’m back and ready to roll. So, first I hypothesise as to why it doesn’t recognise correct answers; I posit that the type of variables I am comparing (text and records[I][1]) are not the same. Let’s find out the types of each of these by printing them.

We know (thanks to vscode’s Go package), that reader.ReadString returns a string. What does csv.Reader.ReadAll return? A 2-dimensional slice of with strings. Hm. Using this little bit of nasty code, I can confirm they are both the same type. So what the hell is going on!

fmt.Println(fmt.Sprintf(“%T”, text)) // string
fmt.Println(fmt.Sprintf(“%T”, records[I][1])) // string

Time for a new hypothesis; but first, some refactoring. I’m finding it a bit difficult to make sense of what I’m writing, mainly because of all these horrible names, like records[I][1].
I’m going to turn these record’s into what they are; items in a quiz. How, you say? By making a struct!

Go’s structs are typed collections of fields. They’re useful for grouping data together to form records, and are pretty essential if you want to do OOP in Go. Go isn’t a pure object oriented language, but through methods and structs, you can write object-oriented code.

Here’s how to define a struct in Go, the aptly named quizItem

type quizItem struct {
  question string
  answer   string
}

We start with the keyword type, since Go is statically typed, and we are defining a new type of variable. Followed by the name of the struct, quizItem, and finally the keyword struct. In the body of the curly braces, we define the structs attributes, followed by their type.

Here’s how the quiz loop looks now that we’ve added a struct

/// omitted unchanged code for brevity
for I := 0; I < len(records); I++ {
  // Create quizItem object
  quizItem := quizItem{records[I][0], records[I][1]}
  // Print out the question
  fmt.Println(“Question: “, quizItem.question)
  // Create reader and allow user to input their answer
  reader := bufio.NewReader(os.Stdin)
  fmt.Print(“Enter your answer now: “)
  // Expect answer to be given once they hit return
  text, _ := reader.ReadString(‘\n’)

  if text == quizItem.answer {
    fmt.Println(“Correct!”)
  } else {
    fmt.Println(“WRONG! Answer is: “, quizItem.answer)
  }
}

As you can see on line 3, instantiating the struct is pretty straight forward, and now the code is a hell of lot more readable. Now that it’s easier to read, time to make a new hypothesis as to why the answer comparison does not work. I hypothesise that perhaps I’m making an assumption on what the value of text is going to be.

Let’s print it out and check! I’ll print the user’s answer before running the comparison check, so now the code looks like this

/// omitted unchanged code for brevity
for I := 0; I < len(records); I++ {
  // Create quizItem object
  quizItem := quizItem{records[I][0], records[I][1]}
  // Print out the question
  fmt.Println(“Question:”, quizItem.question)
  // Create reader and allow user to input their answer
  reader := bufio.NewReader(os.Stdin)
  fmt.Print(“Enter your answer now: “)
  // Expect answer to be given once they hit return
  text, _ := reader.ReadString(‘\n’)
  fmt.Println(“Your answer is:”, text)

  if text == quizItem.answer {
    fmt.Println(“Correct!”)
  } else {
    fmt.Println(“WRONG! Answer is:”, quizItem.answer)
  }
}

$ go build && ./GopherQuiz
Question: 5+5
Enter your answer now:10

Your answer is: 10
WRONG! Answer is: 10
Question: 7+3
Enter your answer now:

Something here is odd; there a new line after printing the user’s answer. Let’s investigate it by looking at the base16 value of the string. We can do this by using fmt.Printf(“%x”, text), where %x is a format modifier signifying that I want the string to formatted in base16. Let’s write some code to test this out;

fmt.Println("Your answer is:", text)
fmt.Printf("Your answer in base16 is %x \n", text)
fmt.Printf("The expected answer in base16 is %x \n", quizItem.answer)

$ go build && ./GopherQuiz
Question: 5+5
Enter your answer now:10
Your answer is: 10

Your answer in base16 is 31300a
The expected answer in base16 is 3130

Aha! My suspicions are confirmed; there /is/ a difference between the two. The user input ends in 0a, which is hex code for linefeed.

What’s happened here is that when reading from stdin, we took everything up to and including \n, which is the reason why there was a new line after printing the user’s input.

Now that we know the issue, how can we solve it? The simplest way would be to remove the linefeed character from the input before comparing. Let’s use the strings package, which is a library of tools for manipulating strings. A quick test:

text = strings.TrimSuffix(text, “\n”)
fmt.Printf(“Your answer trimmed in base16 is %x \n”, text)
fmt.Printf(“The expected answer in base16 is %x \n”, quizItem.answer)

$ go build && ./GopherQuiz
Question: 5+5
Enter your answer now:10
Your answer is: 10

Your answer trimmed in base16 is 3130
The expected answer in base16 is 3130

Success! So what we’ve done here is use the TrimSuffix method, passing it the text we want to apply the trim to, and the suffix we wish to trim. With this, the quiz should work! Here’s a quick reminder of how the entire program looks;

package main

import (
"bufio"
"encoding/csv"
"fmt"
"log"
"os"
"strings"
)

type quizItem struct {
  question string
  answer   string
}

func main() {
  csvFile, err := os.Open("problems.csv")
  if err != nil {
    log.Fatal(err)
  }
  defer csvFile.Close()

  reader := csv.NewReader(csvFile)
  records, err := reader.ReadAll()

  if err != nil {
    log.Fatal(err)
  }

  for i := 0; i < len(records); i++ {
    // Create quizItem object
    quizItem := quizItem{records[i][0], records[i][1]}
    // Print out the question
    fmt.Println("Question:", quizItem.question)
    // Create reader and allow user to input their answer
    reader := bufio.NewReader(os.Stdin)
    fmt.Print("Enter your answer now: ")
    // Expect answer to be given once they hit return
    text, _ := reader.ReadString('\n')
    fmt.Println("Your answer is:", text)
    // Trim the newline suffix from the input
    text = strings.TrimSuffix(text, "\n")
    if text == quizItem.answer {
      fmt.Println("Correct! Well done")
    } else {
      fmt.Println("WRONG! Answer is:", quizItem.answer)
    }
  }

}

And this is how it looks like in action!

So the next things we need to do are;

Keep track of the score, and output how many are correct/wrong
Add a flag that allows the CSV file to be customised.

But before we go any further, we must have tests! Having tests helps you understand your code, saves you time from having to manually test things, and also gives you a little rush every time it all goes green.

Follow me on twitter if you wanna ask me questions or have any suggestions!