-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start adding unit tests #1
Changes from 7 commits
f6b7fba
4f7f854
15c0b82
ec991b5
99d5ed6
4260976
9fae8d8
c674a2a
329feaa
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
package main | ||
|
||
import ( | ||
"bytes" | ||
"os" | ||
"testing" | ||
// "flag" | ||
) | ||
|
||
// TestMainHelp is a test function that verifies the output of the main function. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. general comment: thanks a lot for the comments, they are very useful! I think after some time, we can simply discard them, as otherwise the text will become a little too dense, especially if they are on third-party or native go functions There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, eventually the comments could be reduced. |
||
// It captures the stdout, runs the main function, and checks if the output contains the expected strings. | ||
// This just checks if the main function prints the help message. | ||
func TestMainHelp(t *testing.T) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. food for thought: I think this could be simplified mocking fmt.Printf and asserting that this is called with "\n\nTool to ingest datasets to the data catalog.\n\n". https://stackoverflow.com/questions/52315410/mocking-go-methods. This could be some googling though, so happy to keep it as is! |
||
// Capture stdout | ||
// The variable 'old' stores the original value of the standard output (os.Stdout). | ||
old := os.Stdout | ||
// r is a ReadCloser that represents the read end of the pipe. | ||
// w is a WriteCloser that represents the write end of the pipe. | ||
// err is an error variable. | ||
// The os.Pipe() function in Go is used to create a synchronous in-memory pipe. It can be used for communication between different parts of the program. | ||
// The `os.Pipe()` function in Go is used to create a synchronous in-memory pipe. It can be used for communication between different parts of your program. | ||
// This function returns two values: a `*os.File` for reading and a `*os.File` for writing. When you write data to the write end of the pipe, it becomes available to read from the read end of the pipe. This can be useful for passing data between goroutines or between different parts of your program without using the disk. | ||
r, w, err1 := os.Pipe() | ||
if err1 != nil { | ||
// The Fatalf method is similar to log.Fatalf or fmt.Printf in that it formats a string according to a format specifier and arguments, then logs that string as an error message. However, in addition to this, Fatalf also ends the test immediately. No further code in the test function will be executed, and the test will be marked as failed. | ||
t.Fatalf("Could not start the test. Error in reading the file: %v", err1) | ||
} | ||
// redirect the standard output (os.Stdout) to a different destination, represented by w. | ||
// By default, anything written to os.Stdout will be printed to the terminal. | ||
// The w in this line of code is expected to be a value that satisfies the io.Writer interface, which means it has a Write method. This could be a file, a buffer, a network connection, or any other type of destination for output. | ||
// Since w is connected to r, anything written to w can be read from r. This is how we will capture the output of the main function. | ||
os.Stdout = w | ||
|
||
// Restore stdout after the test | ||
// defer is a keyword that schedules a function call to be run after the function that contains the defer statement has completed. | ||
defer func() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I saw golang has setup/tear down test syntax: https://pkg.go.dev/testing#hdr-Main. Maybe this is fine like it is for now though... |
||
os.Stdout = old | ||
}() | ||
|
||
// Run main function (assuming your main function does not take any arguments) | ||
main() | ||
|
||
// Close pipe writer to flush the output | ||
w.Close() | ||
|
||
//declares a variable named buf of type bytes.Buffer. The bytes.Buffer type is a struct provided by the Go standard library that implements the io.Reader and io.Writer interfaces. | ||
var buf bytes.Buffer | ||
// Copy pipe reader output to buf | ||
// ReadFrom reads data from the given reader r and writes it to the buffer buf. | ||
// It returns the number of bytes read and any error encountered. | ||
_, err := buf.ReadFrom(r) | ||
if err != nil { | ||
t.Fatalf("Error reading output: %v", err) | ||
} | ||
|
||
// Check if the output contains expected strings | ||
expected := "\n\nTool to ingest datasets to the data catalog.\n\n" | ||
//The bytes.Contains function takes two arguments, both of which are slices of bytes, and checks if the second argument is contained within the first. | ||
// Here, expected is a string, and []byte(expected) converts that string to a slice of bytes. | ||
if !bytes.Contains(buf.Bytes(), []byte(expected)) { | ||
t.Errorf("Expected output %q not found in %q", expected, buf.String()) | ||
} | ||
} | ||
|
||
// Errors with the test above. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what's this part? I'd rather remove it than have it commented, we can add it later. |
||
// // TestIsFlagPassed is a test function that verifies the output of the isFlagPassed function. It checks whether the function returns the expected results for defined and undefined flags. | ||
// func TestIsFlagPassed(t *testing.T) { | ||
// // Save original os.Args | ||
// oldArgs := os.Args | ||
// defer func() { os.Args = oldArgs }() | ||
|
||
// // Define a new flag for testing | ||
// flag.String("testenv", "", "testenv flag") | ||
|
||
// // Set os.Args to simulate command-line input | ||
// os.Args = []string{"cmd", "-testenv", "false"} | ||
|
||
// // Parse flags | ||
// flag.Parse() | ||
|
||
// // Test with a flag that was defined | ||
// if !isFlagPassed("testenv") { | ||
// t.Errorf("isFlagPassed() failed for flag that was defined") | ||
// } | ||
|
||
// // Test with a flag that was not defined | ||
// if isFlagPassed("undefinedflag") { | ||
// t.Errorf("isFlagPassed() succeeded for flag that was not defined") | ||
// } | ||
// } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. missing newline. Maybe consider adding some linting in the CI, so this will fail the tests. https://golangci-lint.run/ (as a side comment, I think the CI addition should have been a PR) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think such things would fail the tests. It didn't fail here because it was a comment. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,10 +2,10 @@ | |
"creationLocation": "/PSI/SLS/CSAXS", | ||
"datasetName": "CMakeCache", | ||
"description": "", | ||
"owner": "Ana Diaz", | ||
"ownerEmail": "ana.diaz@psi.ch", | ||
"ownerGroup": "p17301", | ||
"principalInvestigator": "ana.diaz@psi.ch", | ||
"owner": "Ali Vahdati", | ||
"ownerEmail": "reza.rezaee-vahdati@psi.ch", | ||
"ownerGroup": "[email protected]", | ||
"principalInvestigator": "reza.rezaee-vahdati@psi.ch", | ||
"scientificMetadata": [ | ||
{ | ||
"sample": { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think all these changes shouldn't be here, as they are not covered by tests and we should be able to revert if they fail. So they should be in another PR, potentially with dedicated tests when you'll tackle this component. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These changes cannot be removed or the tests fail. although they are not directly checked for these tests, they are simply wrong code that causes the tests to fail. |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think all these changes shouldn't be here, as they are not covered by tests and we should be able to revert if they fail. So they should be in another PR, potentially with dedicated tests when you'll tackle this component. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as above |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove if not needed