• client/client.go (1 hunks)
• client/client_test.go (55 hunks)
• client/core_test.go (9 hunks)
• client/helper_test.go (3 hunks)
• client/hooks_test.go (36 hunks)
• client/request_test.go (16 hunks)
• client/response_test.go (15 hunks)
• middleware/proxy/proxy_test.go (6 hunks)

client/helper_test.go (3)

• 95-95: The change from NewClient() to New() aligns with the PR's objective to simplify naming according to Go conventions. This update is correctly applied in the context of creating a client instance for testing.
• 122-122: Similar to the previous comment, the update from NewClient() to New() is correctly applied here for initializing a client instance in a failure test scenario. This maintains consistency with the PR's objective.
• 147-147: Again, the transition from NewClient() to New() is observed here in the context of testing client functionality. The change is consistent with the PR's goal and is correctly implemented.

client/core_test.go (9)

• 85-85: The update from NewClient() to New() is correctly applied in the context of setting up a client for a normal request test. This change is in line with the PR's objectives and enhances readability.
• 101-101: The change to use New() for client instantiation in a test scenario where the request returns an error is correctly implemented, adhering to the PR's goal of simplifying naming conventions.
• 118-118: In the context of testing request timeouts, the transition to New() for client creation is correctly applied, maintaining consistency with the refactor's intent.
• 160-160: The use of New() in setting up a client for testing user request hooks is appropriate and aligns with the PR's objectives of naming simplification.
• 177-177: Similarly, the update to New() for initializing a client in the context of testing user response hooks is correctly implemented, adhering to the refactor's goals.
• 194-194: The change to New() for client instantiation in a no-timeout test scenario is correctly applied, consistent with the PR's aim of simplifying naming conventions.
• 208-208: In the context of testing client timeouts, the transition to New() for client creation is correctly applied, aligning with the refactor's intent.
• 221-221: The update from NewClient() to New() for initializing a client in a request timeout test scenario is correctly implemented, adhering to the PR's goal of simplifying naming conventions.
• 235-235: The use of New() in setting up a client for testing request timeout precedence is appropriate and aligns with the PR's objectives of naming simplification.

client/response_test.go (15)

• 40-40: The transition from NewClient() to New() for client instantiation in a success response test is correctly applied, consistent with the PR's aim of simplifying naming conventions.
• 57-57: Similarly, the update to New() for initializing a client in a failure response test is correctly implemented, adhering to the refactor's goals.
• 91-91: The change to New() for client instantiation in a success status code test is correctly applied, aligning with the PR's objectives of naming simplification.
• 108-108: The update from NewClient() to New() for initializing a client in a failure status code test is correctly implemented, adhering to the PR's goal of simplifying naming conventions.
• 133-133: The transition to New() for client creation in an HTTP protocol test is correctly applied, consistent with the refactor's intent.
• 166-166: The use of New() in setting up a client for an HTTPS protocol test is appropriate and aligns with the PR's objectives of naming simplification.
• 190-190: The change to New() for client instantiation in a header test is correctly applied, aligning with the PR's objectives of naming simplification.
• 215-215: Similarly, the update to New() for initializing a client in a cookie test is correctly implemented, adhering to the refactor's goals.
• 253-253: The transition from NewClient() to New() for client instantiation in a raw body test is correctly applied, consistent with the PR's aim of simplifying naming conventions.
• 270-270: The update to New() for setting up a client in a string body test is correctly implemented, adhering to the refactor's goals.
• 290-290: The change to New() for client instantiation in a JSON body test is correctly applied, aligning with the PR's objectives of naming simplification.
• 315-315: Similarly, the update to New() for initializing a client in an XML body test is correctly implemented, adhering to the refactor's goals.
• 350-350: The transition from NewClient() to New() for client instantiation in a file path save test is correctly applied, consistent with the PR's aim of simplifying naming conventions.
• 386-386: The update to New() for setting up a client in an io.Writer save test is correctly implemented, adhering to the refactor's goals.
• 407-407: The change to New() for client instantiation in an error type save test is correctly applied, aligning with the PR's objectives of naming simplification. However, it's worth noting that the test checks for an error when saving to a nil destination, which is a good practice for validating error handling in the API.

client/hooks_test.go (2)

• 51-51: The change from NewClient() to New() aligns with Go's naming conventions and simplifies the function call within the context of the client package. This modification enhances readability and adheres to the principle of eliminating redundancy in naming.
• 522-522: The test case for "raw body error" correctly simulates a scenario where the body is set to nil after being initially set, which should trigger an error. This is a good practice for testing error handling paths in the code. However, it's important to ensure that the error handling is consistent across all similar scenarios and that the error messages provided to the user are clear and helpful.

middleware/proxy/proxy_test.go (6)

• 141-141: The change from clientpkg.NewClient() to clientpkg.New() correctly follows the PR's objective to adhere to Go naming conventions and eliminate redundancy. This instance specifically updates the client initialization for a test involving TLS configuration.
• 179-179: The replacement of clientpkg.NewClient() with clientpkg.New() here is consistent with the PR's goal. Additionally, setting a timeout and configuring TLS to skip verification are appropriate for this test scenario, which involves forwarding with TLS configuration to HTTP.
• 244-244: This change aligns with the PR's objectives and correctly updates the client initialization for a test case that forwards requests with a client TLS configuration. The use of clientpkg.New() and setting the TLS configuration are correctly implemented.
• 599-599: The transition to clientpkg.New() from clientpkg.NewClient() is correctly applied in the context of testing proxy forwarding with a global client. This change is in line with the PR's objectives and maintains consistency across the test suite.
• 631-631: Using clientpkg.New() here for testing proxy forwarding with a local client is consistent with the PR's objectives. The change is correctly implemented and contributes to the overall goal of simplifying and standardizing function naming within the package.
• 709-709: The replacement of clientpkg.NewClient() with clientpkg.New() in this test case for domain forwarding is correctly executed. This change adheres to the PR's objectives and ensures that the new naming convention is consistently applied across the test suite.

client/client.go (1)

• 689-693: The renaming of the ClientNew function to New aligns with Go's naming conventions, enhancing readability and maintainability. This change is straightforward and correctly implemented. However, it's crucial to ensure that all references to this function across the project, especially in test files and documentation, are updated to reflect this change.

client/client_test.go (44)

• 65-65: The refactor from NewClient to New is correctly applied here, aligning with Go naming conventions for simplicity and readability.
• 85-85: The change from NewClient to New is correctly applied in the context of adding response hooks. This maintains consistency with the refactor's objectives.
• 107-107: The refactor from NewClient to New is correctly applied in the test for checking the order of hooks. This change is consistent with the PR's objectives.
• 133-133: The change from NewClient to New is correctly applied in the context of setting JSON marshal functions. This maintains the refactor's consistency.
• 147-147: The change from NewClient to New is correctly applied in the context of setting JSON marshal functions with error handling. This maintains the refactor's consistency.
• 159-159: The change from NewClient to New is correctly applied in the context of setting JSON unmarshal functions. This maintains the refactor's consistency.
• 170-170: The change from NewClient to New is correctly applied in the context of setting JSON unmarshal functions with error handling. This maintains the refactor's consistency.
• 181-181: The change from NewClient to New is correctly applied in the context of setting XML marshal functions. This maintains the refactor's consistency.
• 193-193: The change from NewClient to New is correctly applied in the context of setting XML marshal functions with error handling. This maintains the refactor's consistency.
• 205-205: The change from NewClient to New is correctly applied in the context of setting XML unmarshal functions. This maintains the refactor's consistency.
• 216-216: The change from NewClient to New is correctly applied in the context of setting XML unmarshal functions with error handling. This maintains the refactor's consistency.
• 229-229: The change from NewClient to New is correctly applied in the context of setting the base URL. This maintains the refactor's consistency.
• 245-245: The change from NewClient to New is correctly applied in the context of handling invalid URLs. This maintains the refactor's consistency.
• 255-255: The change from NewClient to New is correctly applied in the context of handling unsupported protocols. This maintains the refactor's consistency.
• 271-271: The change from NewClient to New is correctly applied in the context of concurrency requests. This maintains the refactor's consistency.
• 323-323: The change from NewClient to New is correctly applied in the context of the client GET request. This maintains the refactor's consistency.
• 364-364: The change from NewClient to New is correctly applied in the context of the client HEAD request. This maintains the refactor's consistency.
• 415-415: The change from NewClient to New is correctly applied in the context of the client POST request. This maintains the refactor's consistency.
• 471-471: The change from NewClient to New is correctly applied in the context of the client PUT request. This maintains the refactor's consistency.
• 530-530: The change from NewClient to New is correctly applied in the context of the client DELETE request. This maintains the refactor's consistency.
• 584-584: The change from NewClient to New is correctly applied in the context of the client OPTIONS request. This maintains the refactor's consistency.
• 639-639: The change from NewClient to New is correctly applied in the context of the client PATCH request. This maintains the refactor's consistency.
• 691-691: The change from NewClient to New is correctly applied in the context of setting a custom user agent. This maintains the refactor's consistency.
• 708-708: The change from NewClient to New is correctly applied in the context of adding a header. This maintains the refactor's consistency.
• 719-719: The change from NewClient to New is correctly applied in the context of setting a header. This maintains the refactor's consistency.
• 729-729: The change from NewClient to New is correctly applied in the context of adding multiple headers. This maintains the refactor's consistency.
• 749-749: The change from NewClient to New is correctly applied in the context of setting multiple headers. This maintains the refactor's consistency.
• 767-767: The change from NewClient to New is correctly applied in the context of setting a header case-insensitively. This maintains the refactor's consistency.
• 809-809: The change from NewClient to New is correctly applied in the context of setting a cookie. This maintains the refactor's consistency.
• 819-819: The change from NewClient to New is correctly applied in the context of setting multiple cookies. This maintains the refactor's consistency.
• 841-841: The change from NewClient to New is correctly applied in the context of setting cookies with a struct. This maintains the refactor's consistency.
• 852-852: The change from NewClient to New is correctly applied in the context of deleting cookies. This maintains the refactor's consistency.
• 1169-1169: The change from NewClient to New is correctly applied in the context of setting a path parameter. This maintains the refactor's consistency.
• 1179-1179: The change from NewClient to New is correctly applied in the context of setting multiple path parameters. This maintains the refactor's consistency.
• 1201-1201: The change from NewClient to New is correctly applied in the context of setting path parameters with a struct. This maintains the refactor's consistency.
• 1212-1212: The change from NewClient to New is correctly applied in the context of deleting path parameters. This maintains the refactor's consistency.
• 1235-1235: The change from NewClient to New is correctly applied in the context of setting a path parameter and making a GET request. This maintains the refactor's consistency.
• 1266-1266: The change from NewClient to New is correctly applied in the context of setting TLS configuration. This maintains the refactor's consistency.
• 1299-1299: The change from NewClient to New is correctly applied in the context of setting TLS configuration and handling errors. This maintains the refactor's consistency.
• 1329-1329: The change from NewClient to New is correctly applied in the context of making a TLS request without setting a TLS configuration explicitly. This maintains the refactor's consistency.
• 1343-1343: The change from NewClient to New is correctly applied in the context of setting certificates. This maintains the refactor's consistency.
• 1350-1350: The change from NewClient to New is correctly applied in the context of setting a root certificate from a file. This maintains the refactor's consistency.
• 1364-1364: The change from NewClient to New is correctly applied in the context of setting a root certificate from a string. This maintains the refactor's consistency.
• 1371-1371: The change from NewClient to New is correctly applied in the context of creating a new request. This maintains the refactor's consistency.

client/request_test.go (2)

• 70-70: The change from NewClient() to New() aligns with the PR's objectives and follows Go's naming conventions. Good job on making the code more idiomatic.
• 649-649: The refactor from NewClient() to New() is consistently applied across various test functions, maintaining the integrity of the test suite while adhering to Go's naming conventions.