Skip to content
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

Fix make test (Issue #14) #35

Merged
merged 3 commits into from May 31, 2020
Merged

Fix make test (Issue #14) #35

merged 3 commits into from May 31, 2020

Conversation

yoyoma2
Copy link

@yoyoma2 yoyoma2 commented Jan 21, 2019

As the title states, this pull request fixes "make test" thus closing Issue #14. The failing tests were all using the ace of spades as the current card in both the source and destination stacks which can never be a valid move. The valid_move() function actually works fine as long as the test code sends valid cards when it expects a valid return code.

NB: This pull request only touches test code and makes absolutely no changes to game code.

Copy link
Contributor

@greno4ka greno4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the function valid_move is correct, so obviously the problem in tests. I wanted to make the same changes, but dont you think, that these modifications will change the sense of these tests? Have you looked on other tests?

@yoyoma2
Copy link
Author

yoyoma2 commented Jan 21, 2019

dont you think, that these modifications will change the sense of these tests? Have you looked on other tests?

Since only the ace of spades was used as source and destination card in all of the failed tests they were all performing the same test (ace clubs to ace clubs = fail). By using different cards, these tests now perform the test intended by their function names. Changing all of the assert() statements to always expect failure would be an easier fix but that would not accomplish the intention of the tests.

Other tests could in fact be improved to be more complete but this change only fixes the failed tests.

Added a bunch of memory free calls to fix all the numerous memory leaks reported by valgrind.

@greno4ka
Copy link
Contributor

Yeah, nice changes! Let's hope, that @mpereira can see them as soon as posible and pull them in new release=)

@mpereira
Copy link
Owner

Yes, don't worry I'm seeing the recent PRs. I'll be taking a look at them soon 🙂

@yoyoma2
Copy link
Author

yoyoma2 commented Jan 23, 2019

Noticed the first card of the first manoeuvre stack was often an ace of diamonds on startup. It turns out the shuffle_deck() function wasn't shuffling the last position. You can still be lucky and another card gets randomly shuffled to that position but start the game 52 times and you'll see the ace of diamonds too often in the first manoeuvre stack. Removing the -1 insures the entire deck gets shuffled. Also on the following line the adding and subtracting of the variable i was deleted since it does nothing to the result of the modulo calculation.

Copy link
Contributor

@greno4ka greno4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's really cool observation!

@mpereira
Copy link
Owner

Hi @yoyoma2,

Thanks for your PR. I had some time today to take a careful look at your changes and they look great! Nice spot with the off-by-one issue in shuffle_deck. It would be nice to have some tests for it at some point...

I'll merge this and do a release.

@mpereira mpereira merged commit 379ef43 into mpereira:master May 31, 2020
@mpereira
Copy link
Owner

By the way, would you be able to share the valgrind command you used? I'll add a Makefile target for it, and soon hook this repository with CI.

This was referenced May 31, 2020
@yoyoma2
Copy link
Author

yoyoma2 commented May 31, 2020

I just put valgrind before the non-stripped/debuggable executable as below. Then played the game and a memory report is printed to the terminal on exiting the game. All leaks were gone.

$ valgrind ttysolitaire
==24173== Memcheck, a memory error detector
==24173== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24173== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==24173== Command: ttysolitaire
==24173== 
==24173== 
==24173== HEAP SUMMARY:
==24173==     in use at exit: 259,066 bytes in 347 blocks
==24173==   total heap usage: 1,941 allocs, 1,594 frees, 541,218 bytes allocated
==24173== 
==24173== LEAK SUMMARY:
==24173==    definitely lost: 0 bytes in 0 blocks
==24173==    indirectly lost: 0 bytes in 0 blocks
==24173==      possibly lost: 0 bytes in 0 blocks
==24173==    still reachable: 259,066 bytes in 347 blocks
==24173==         suppressed: 0 bytes in 0 blocks
==24173== Rerun with --leak-check=full to see details of leaked memory
==24173== 
==24173== For counts of detected and suppressed errors, rerun with: -v
==24173== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$

@yoyoma2
Copy link
Author

yoyoma2 commented May 31, 2020

If you are automating tests then this command is more useful. It also gave zero memory errors after the pull request but I'm not sure it tests as many code paths as the real game.

$ valgrind ttysolitaire_test 
==24428== Memcheck, a memory error detector
==24428== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24428== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==24428== Command: ttysolitaire_test
==24428== 
==24428== 
==24428== HEAP SUMMARY:
==24428==     in use at exit: 0 bytes in 0 blocks
==24428==   total heap usage: 639 allocs, 639 frees, 11,992 bytes allocated
==24428== 
==24428== All heap blocks were freed -- no leaks are possible
==24428== 
==24428== For counts of detected and suppressed errors, rerun with: -v
==24428== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$

@mpereira
Copy link
Owner

Yeah, for CI running valgrind on the test executable might be more fitting. Thanks for sharing.

@yoyoma2
Copy link
Author

yoyoma2 commented May 31, 2020

Oh and the "in use at exit" in the game's case is not ttysolitaire's fault but a normal side effect of using ncurses as explained here.

@mpereira
Copy link
Owner

Thanks for the context 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants