1
\$\begingroup\$

Here is an initial attempt at unit test of user input in C. The thing that feels unusual is the use of freopen to send the test data to stdin. Are there better ways to implement this kind of test?

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
static size_t get_num(size_t tmpnum) {
 if (scanf("%zu", &tmpnum) != 1) {
 fprintf(stderr, "ERROR: system error: failed to read input, exiting.\n");
 exit(1);
 }
 return tmpnum;
}
int main(void)
{
 int return_status = 0;
 /* Test 1 */
 if (freopen("test-data.txt", "r", stdin) != NULL) {
 size_t tmpnum = 0;
 tmpnum = get_num(tmpnum);
 assert(tmpnum >= 1 && tmpnum <= 20);
 printf("ok: tmpnum == %ld\n", tmpnum);
 freopen("/dev/stdin", "r", stdin);
 } else {
 printf("ERROR: failed to open test-data.txt\n");
 return_status = EXIT_FAILURE;
 }
 return return_status;
}
200_success
145k22 gold badges190 silver badges478 bronze badges
asked Jan 24, 2019 at 19:54
\$\endgroup\$
0

1 Answer 1

1
\$\begingroup\$

The thing that feels unusual is the use of freopen to send the test data to stdin.

Are there better ways to implement this kind of test?

C has a freopen() footnote

The primary use of the freopen function is to change the file associated with a standard text stream (stderr, stdin, or stdout), as those identifiers need not be modifiable lvalues to which the value returned by the fopen function may be assigned.

This looks like a good direct way to test code, although I'd expect stdout, strderr being re-opened to capture output.


Are there better ways

Enable all compiler warnings - save time.

The mismatch of specifier and type implies code is not efficiently using the 1st round of code improvement: Compiler warnings.

// printf("ok: tmpnum == %ld\n", tmpnum);
printf("ok: tmpnum == %zu\n", tmpnum);

Code is strange in that it passes in tmpnum for no good reason.

//static size_t get_num(size_t tmpnum) {
// if (scanf("%zu", &tmpnum) != 1) {
static size_t get_num(void) {
 size_t tmpnum;
 if (scanf("%zu", &tmpnum) != 1) {
answered Jan 25, 2019 at 2:27
\$\endgroup\$
4
  • \$\begingroup\$ 1. Not sure what you mean about stdout and stderr. The code doesn't change them, should it? \$\endgroup\$ Commented Jan 25, 2019 at 19:53
  • \$\begingroup\$ 2. There weren't any compiler warnings for the specifier missmatch. I used this compiler command: clang -Wall -Wextra -Weverything -pedantic code_review.c -o code_review.o. I corrected the specifier anyways as you suggested. \$\endgroup\$ Commented Jan 25, 2019 at 20:05
  • \$\begingroup\$ 3. @chux Thanks for pointing out the that tmpnum didn't need to be passed to get_num(). I've removed it. \$\endgroup\$ Commented Jan 25, 2019 at 20:08
  • \$\begingroup\$ @RunwayBlues The idea of re-opening stderr, stdout would allow the test code a step towards automatically testing if get_num() performed as expected. It appears that atexit() would also be needed to catch the fprintf(stderr, "ERROR: system error: failed to read input, exiting.\n"); exit(1);. It simply comes down to how much do you want to wrap around the testing of get_num() to provide/catch all its input/output. \$\endgroup\$ Commented Jan 26, 2019 at 0:01

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.