How do i apply unit testing to check leap year with golang?

I want to do unit testing and check if dates are leap year or not, how do i apply unit testing in this case, i don’t t know how to go about it in this situation?

I have already created my function and it works fine, i also have a JSON file that contains list of people and their Birthday dates !

Would appreciate some feedback or advice on how to tackle this problem ! Thanks

BD.go:

 package main
import (
"encoding/json"
"fmt"
"io/ioutil"
"log"
"os"
"time"
)
// Users struct which contains
// an array of users
type Users struct {
Users []User `json:"users"`
}
// User struct which contains a name
// a type and a list of social links
type User struct {
Firstname  string `json:"fname"`
Secondname string `json:"lname"`
Date       string `json:"date"`
}
var users Users
var user User
func Birthday() {
// Open our jsonFile
jsonFile, err := os.Open("users.json")
// if we os.Open returns an error then handle it
if err != nil {
fmt.Println(err)
}
fmt.Println("Successfully Opened users.json")
// defer the closing of our jsonFile so that we can parse it later on
defer jsonFile.Close()
// read our opened xmlFile as a byte array.
byteValue, _ := ioutil.ReadAll(jsonFile)
// we initialize our Users array
// we unmarshal our byteArray which contains our
// jsonFile's content into 'users' which we defined above
json.Unmarshal(byteValue, &users)
IsLeapYear("users.json")
}
func IsLeapYear(user string) bool {
// we iterate through every user within our users array and
// print out the user Type, their name
for i := 0; i < len(users.Users); i++ {
date, err := time.Parse("2006/01/02", users.Users[i].Date)
if err != nil {
date, err = time.Parse("2006-01-02", users.Users[i].Date)
// date, err = time.Parse("2006 01 02", users.Users[i].Date)
if err != nil {
log.Fatal("unsupported date format:", err)
}
}
// check if the date is a leap year, ex: 29 is not a leap year but 28th is !
if date.Day()%400 == 0 || (date.Day()%4 == 0 && date.Day()%100 != 0) {
fmt.Println("User First Name: " + users.Users[i].Firstname)
fmt.Println("User Second Name: " + users.Users[i].Secondname)
fmt.Println("User Date: " + users.Users[i].Date)
fmt.Println(users.Users[i].Date, "is a Leap Year ✨ ✨ ✨")
// checking if the date.day matches today's date
if date.Day() == time.Now().Day() {
fmt.Println("User First Name: " + users.Users[i].Firstname)
fmt.Println("User Date: " + users.Users[i].Date)
fmt.Println("TODAY IS YOUR BIRTHDAY, Happy birthday !!!🎉 🎉 🍾 🍾 ")
// not ur birthday today because the date in the json doesn't match todays date
} else {
fmt.Println("TODAY IS NOT YOUR BIRTHDAY..!!!")
}
} else {
fmt.Println("User First Name: " + users.Users[i].Firstname)
fmt.Println("User Second Name: " + users.Users[i].Secondname)
fmt.Println("User Date: " + users.Users[i].Date)
fmt.Println(users.Users[i].Date, " is Not a Leap Year 💥 💥 💥 ")
}
}
return false
}
func main() {
Birthday()
}

bd_test.go:

package main

import (
"testing"
"time"
"github.com/stretchr/testify/assert"
)
//main_test.go
type dateTest struct {
date   time.Time
expect bool
}
var dateTests = []dateTest{
{"2021-07-28", true},
{time.Date(2021,9,10), false},
}
func TestIsLeapYear(t *testing.T) {
for _, tc := range dateTests {
result := IsLeapYear(tc.date)
assert.Equal(t, tc.expect, result)
}
}

users.JSON:

{
"users": [
{
"Fname": "Johnny",
"Lname":"mane",
"date":"1982/01/08"
},
{
"Fname": "Wayne",
"Lname":"Bruce",
"date":"1965/01/30"
},
{
"Fname": "Gaga",
"Lname":"Lady",
"date":"1986/03/08"
},
{
"Fname": "radio",
"Lname":"head",
"date":"1988/02/29"
},
{
"Fname": "Mario",
"Lname":"torres",
"date":"1996/09/04"
},
{
"Fname": "robert",
"Lname":"Alex",
"date":"1991/12/05"
},
{
"Fname": "Julia",
"Lname":"sevak",
"date":"1991-03-28"
},
{
"Fname": "feb",
"Lname":"robert",
"date":"1995-05-24"
},
{
"Fname": "Liam",
"Lname":"Noah",
"date":"2002-10-04"
},
{
"Fname": "alex",
"Lname":"sam",
"date":"2021/10/21"
}
}
]
}

You code would require some refactoring to make it testable. Currently you can't really test the code, as the functions in your code do not return anything. In a unit test you call a function and validate it's output (generally speaking).

So to make your code testable you'll have to restructure certain parts of the code in separate functions. I'll show you an example for the leap year:

//main.go
func IsLeapYear(date time.Time) bool {
  if date.Year() % 400 == 0 {
    return true
  }
  return date.Year()%4 == 0 && date.Year()%100 != 0
}

in your test file:

//main_test.go
type dateTest struct {
  date time.Time
  expect bool
}

var dateTests = []dateTest{
  // your test data
}

func TestIsLeapYear(t *testing.T){
  for _, tc := range dateTests {
    result := IsLeapYear(tc.data)
    assert.Equal(t, tc.expect, result)
  }
}

Regarding your updated code:

I'll begin with the single most important piece of advice I have for you: stop ignoring errors! Checking errors is absolutely critical to debugging your Go code and also operating your program. Remember that unlike many higher level languages like Javascript, there are no exceptions in Go. Your checking of error returns is the only chance you have to catch those errors.

For example:

    json.Unmarshal(byteValue, &users)

That line returns an error if the json is invalid. You should check it. Look up the documentation on each of the library functions you use that you haven't memorized - I do - and make sure you are consuming those error messages.

Okay, let's take a look at what you're passing to IsLeapYear:

    jsonFile, err := os.Open("users.json")
...
IsLeapYear("users.json")

by the time you get to IsLeapYear you're past the point where you need the file name. You've already opened that file and unmarshaled its value to a Users struct. So you certainly don't need to pass it the file name.

Let me highlight something Pim showed you that you didn't follow faithfully:

func IsLeapYear(date time.Time) bool

The fact that Pim's IsLeapYear checks one date is important. Your test cases are individual dates that need to be individually checked. But your IsLeapYear iterates over a whole list of dates. You can't feed specific dates to be checked to that. Your leap year also expects to receive multiple dates, but you only return one bool, so that single return value can't possibly tell you the result of the leap year checks on each of the multiple dates you may have passed.

Follow Pim's suggestion for IsLeapYear - it should have exactly one argument and it should be a time.Time. First and Last name is not relevant to IsLeapYear so it doesn't need to be passed. IsLeapYear does not need to parse dates - their format is incidental to the way you stored your data in json, and is not relevant to whether the date they represent is a Leap Year.

> Aim for 10-20 line functions.

The reason I make this suggestion, is because long functions almost always are doing too much and it's a sign that you need to refactor your functions to better match the components of your algorithm. Let's break up your code into pseudocode to better reflect your algorithm:

<ul>
<li>Read Users from json file</li>
<li>For each user: <ul>
<li>parse its date from the expected format
<li>if it is a leap year birthday
<ul>
<li>print user info
<li>print leap year message
<li>if birthdate is today, print user info and birthday message
<li>else print not birthday message
</ul>
</li>
<li>else print user info and not birthday message
</ul>
</ul>

From that we can identify some functions we might write:

• func ReadUsersFromJson(filename string) (*Users, err)
• func ParseUserDateString(date string) (time.Time, error)
• func IsLeapYear(date time.Time) bool
• func PrintUserInfo(u User)
• func IsTodaysDate(date time.Time) bool

Each of these functions is pretty straight forward and short, and only does one thing. Each of them could be tested in turn. Your general approach to testing is common: write a whole list of inputs ( and expeected outputs - you missed that part) , then iterate over the list, passing each of the inputs to the function being tested, and verifying that its result was what you expected.

For ReadUsersFromJson you could have a tests/ directory with some json files you test against. You could test both success and error cases with valid and invalid json.

Similarly, ParseUserDateString test data might look something like:

struct ParseUserDateStringTestData {
input string
expected time.Time
exp_err_msg string
}

Then you can test both success and failure cases there. And so on for the rest of the functions.

Once all the functions are written and tested, it's just a question of assembling all the functions together in Birthday().

func Birthday() {
users, err := ReadUsersFromJson("users.json")
if err != nil {
panic(fmt.Errorf("Failed to read from Json: %w", err))
}
for _, user := range users.Users {
if d, err := ParseUserDateString(user.Date); err != nil {
panic(fmt.Errorf("Date %s could not be parsed: %w", user.Date, err))
} else if IsLeapYear(d) {
PrintUserInfo(user)
fmt.Printf("Leap year message!")
if IsTodaysDate(d) {
fmt.Printf("birthday message!")
} else {
fmt.Printf("Not birthday message!")
}
} else {
fmt.Printf("Not leap year message!")
}
}
}

It just so happens to come in at 20 lines, and it also is quite clear what it's doing. You'll notice that since I wrote PrintUserInfo it removed a bunch of duplication in Birthday. This duplication makes the function harder to read and manage of course.

If you write functions like the ones I lay out, and test all of them, your program should come together nicely. Notice that main() or Birthday() do not need to be written to test the other functions. It's a good idea to test your functions as you write them, so as not to end up with a huge backlog of tests, and to instill confidence in the code you've written.

Case in point:

            if date.Day() == time.Now().Day() {

I don't think that's doing what you think it's doing. Day() is actually the day of the month, so you're actually just saying, is the day of the date the same day of the month as today's day? The 29th of any month would be the same Day() as the 29th of February. Testing would prove whether or not this was the case, then you could rely on that functionality later.