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;
}
\$\endgroup\$
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) {
\$\endgroup\$
  • \$\begingroup\$ 1. Not sure what you mean about stdout and stderr. The code doesn't change them, should it? \$\endgroup\$ – DC Slagel Jan 25 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\$ – DC Slagel Jan 25 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\$ – DC Slagel Jan 25 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\$ – chux Jan 26 at 0:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.