• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Deck Shuffle JUnit Help

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello!

I'm new here and also new to Java!  I recently just started learning Java and have been learning for about 2 months now.
For the past few months, I been doing okay with most of the codes until JUnit was introduced to me...  I've been struggling lately
with JUnit because my sensei never really taught me it in class, he just told me to look stuff up online.  I have been trying to learn by looking online,
but I'm having trouble understanding it.

I am here to ask for help to help me understand what I'm doing wrong and of course, to learn more above Java!
Anyways, I have been trying to figure out how to do this JUnit assignment for the past 5 hours, but I'm having no luck

I need to make a JUnit shuffle test for Deck.java.  

For testing, since there are 52 different cards it is not feasible to test every card as such when the Deck is first created just make sure the start and end suit for the 2’s and Ace’s is in the correct place.  For shuffle, the testing gets even harder because the cards may or may not move.  Let’s assume that if at least 50% of the cards are not in their original place that the shuffle test passes.  So you will need to get the cards before and after the shuffle and count how many are no longer in their original location.  (Hint: Because arrays are pass-by reference you may find it easy to test this using two different instances of Deck, one shuffled and one un-shuffled)




Deck.java


And this is the JUnit code I have for shuffle test so far.


Please tell me what I'm doing wrong and help me understand everything I'm missing or everything that I have wrong.
Any help would be greatly appriciated, thanks!
 
Marshal
Posts: 14336
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch!

Is that code in shuffle() your implementation or was that provided by your teacher? It's not a very good algorithm. A better way would be to start from the end and iteratively reduce the range of index values you're randomly picking from. That is, pick a random card from [0] to [length -1] and swap it with the card at [length-1]. Then pick another random card from [0] to [length-2] and swap it with the card at [length-2]. Pick from [0] to [length-3] and swap with [length-3] and so on. This ensures that cards you've already randomly picked don't get moved again. In your algorithm, there's a greater chance that cards just get moved back to where they were originally or that they don't get moved at all.

Alternatively, there is an easier and more reliable way: shuffle arrays in Java with Collections.shuffle() although I don't know if you're allowed to use that (I suspect you aren't).

You can't just use equals() with arrays the way you're doing it. That doesn't work like you think it does because arrays don't override Object.equals(). If you fire up jshell (Java's REPL), you can try this:

jshell> int[] nums1 = {1, 2, 3, 4}
nums1 ==> int[4] { 1, 2, 3, 4 }

jshell> int[] nums2 = {1, 2, 3, 4}
nums2 ==> int[4] { 1, 2, 3, 4 }

jshell> nums1.equals(nums2)
$3 ==> false

As you can see, even though the two arrays have exactly the same elements, nums1.equals(nums2) still gives you false.

See java.util.Arrays.equals() and java.util.Arrays.deepEquals()

jshell> java.util.Arrays.equals(nums1, nums2)
$4 ==> true

 
Junilu Lacar
Marshal
Posts: 14336
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, this: "you will need to get the cards before and after the shuffle and count how many are no longer in their original location."

Your test code is not currently doing that.
 
Marshal
Posts: 7264
492
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jon, welcome to the Ranch.

Also try to give your tests a more descriptive names, so reading them would be instantaneously clear what they are testing. As they are now, I had to look into their implementation to understand what they are actually trying to test.

For instance this test name:
testUnshuffled()

Perhaps would read better as:
two_unshuffled_decks_are_equal()

In a similar way also with:
testShuffled()

Would read better as:
unshuffled_and_shuffled_decks_arent_equal()

Or even more better as:
unshuffled_deck_after_shuffling_it_is_no_longer_in_same_order() (don't know yet how to express an idea that we are talking about the same deck before and after)

Some suggested more commonly used conventions for naming test methods -> here. I find myself using 4th just separating parts by an underscore _.

Even initially you got those names not that bad comparing to what I saw once: testingHappyCase(). Try to avoid such and similar naming in the future.

Note: you don't need to add "test" word to a test method name. Annotation @Test suggests that already. In some cases prefix "test" maybe it makes clearer though, but just be aware of that.
 
Liutauras Vilda
Marshal
Posts: 7264
492
Mac OS X VI Editor BSD Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You got that test above. Now, if we'd try to look at each line individually, what line 3 tells you?

To me it tells a lie. And look how line 4 reads awkwardly, that suggests that something is off. Maybe just naming (by calling it shuffled initially), but then how you'd communicate whether deck is shuffled or not. I'm not entirely sure whether I'm right or not, but I'd explore an opportunity to make method shuffle() to return a new Deck, a shuffled one.

So you could write:


And if you start gradually think about it more, you probably can even design Deck along such way:

So the line 3 now explicitly tells you that the initial Deck you have is unshuffled, because it says so. But writing this test, I kind of see one thing which might be confusing. If we define such static factory method unshuffled() in a Deck class, one would naturally could expect that there is Deck.shuffled(). And maybe that is if you have such concept too. BUT, in such case you'd end up with 2 ways of getting shuffled Deck (get it initially shuffled, or shuffle unshuffled deck):

[1]
Deck shuffled = Deck.shuffled();

[2]
Deck deck = Deck.unshuffled();
Deck shuffled = deck.shuffle();

So you can fall into the trap oof writing test as:

While actually you'd want to shuffle the same Deck which is initially unshuffled. Sounds confusing probably what I'm at. Could clarify later...
 
Marshal
Posts: 66189
250
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

I am afraid your shuffle algorithm isn't correct. There are all sorts of problems with shuffling a pack of cards, not least that the numbers of combinations (80,658,175,170,943,878,571,660,636,856,403,766,975,289,505,440,883,277,824,000,000,000,000=52!) is so much larger than the range of values for the “seed” for the Random object (18,446,744,073,709,551,616=2⁶⁴) that 99.999...% of the different possibilities can never be reached. Another problem is that the naïve algorithm which always swaps the entire array has a bias towards elements at the beginning of the array, and there is a chance that those elements will be moved several times. This method corrects the second problem, but it only operates on a List. The link explains the algorithm; it iterates the collection backwards and swaps the un‑iterated portion of the collection only. There is a lot more information in this thread and a link to a source of randomness here.
You are also going to have repeated code; you will be using the code in line 33‑35 again and again. Write yourself a utility class:-You can overload that method for arrays of primitives. Come to think of it, you can put the shuffle() method in that class too. Remember to mark all utility class methods static (and probably final too). Then you can write MyUtilities.shuffle(myArray);
Don't return a reference to a mutable reference type (line 51). That allows other code to “see” that object and modify its state without your knowing about it. I don't know whether it is a good idea to return that array at all, but if so, do this: return array.clone(); which will return a copy so any modifications occurring elsewhere won't affect the original. Now, looking at your instructions, I can see I have given you a hint which will be useful for your testing.
Only use CAPITAL_LETTERS for constants; your two arrays aren't constants so they should be called ranks and suits.
Why haven't you given your class a toString() method? If you had, you would write System.out.println(dk); Find out about this method which will probably help you.
Suggest:-
  • About the bias because you are swapping with the whole array: change the algorithm.
  • About the combinations being too many for Random to cope with: pretend you don't know about that.


  • Suggestions for making a method that will test whether more than 50% of the elements have been moved:-
  • 1: You will need a copy of the array before it was randomised. I have already shown you the easiest way to make a (shallow) copy of an array. You don't need a “deep copy” of the array in this situation.
  • 2: You will need a linearSearch() method. Something else for the utility class. Make that method return index, −1 for “not found” and your isShuffled() method should probably throw an exception if it encounters a −1. That would mean you have lost an element, but that shouldn't ever happen. The Arrays class doesn't have a linear search method and you can't use its binary search method because neither version of your array will be in the right order for binary search.
  • Your isShuffled() method can iterate the two versions of the array and count how many elements are not at the same index. If you get to count * 2 >= array.length you can return true. Otherwise false.
  • Come to think of it, you can probably simplify that to checking that at least 26 of the elements are different, with the equals() method. Sounds a lot simpler.
  • You can now convert that method to a test method and call it with assertTrue().
  •  
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:. . . shuffle arrays in Java with Collections.shuffle() . . .

    There isn't an Arrays#shuffle() method, is there? No there isn't. Unfortunately the first hit on that search uses the wrong algorithm for shuffling.

    java.util.Arrays.equals() and java.util.Arrays.deepEquals() . . .

    I think JF won't need deepEquals(). He has been given a definition of 50% of the elements having been moved which should be very easy to achieve.
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    A few minutes ago,, I wrote:. . . Unfortunately the first hit on that search uses the wrong algorithm for shuffling. . . .

    I clicked your link again and got a different lot of results, but these two recent hits use the wrong algorithm: 1 2.
     
    Bartender
    Posts: 3606
    151
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell wrote:1: You will need a copy of the array before it was randomised.


    Yes, but it can be done easier. Instead of 52 cards, one might as well have an array of the ints 0, 1, 2, 3, ..., 51, that can be shuffled with OP's method. It is then very easy to see if at least 50% have moved.
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Good suggestion Apart from the fact that you would need parallel arrays, you could shuffle the int[] at the same time as the String[] to avoid any possible difference between successive runs of the shuffle() method.

    [edit]I can't see the instructions from the reply window, but did they require use of a copy of the original array or only suggest it?
    [edit2]Only a suggestion.
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jon Fil's original instructions wrote:. . . arrays are pass-by reference  . . .

    That should read, “arrays are referene types,” since there is no such thing as pass by reference in Java®.
     
    Piet Souris
    Bartender
    Posts: 3606
    151
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:Apart from the fact that you would need parallel arrays, you could shuffle the int[] at the same time as the String[] to avoid any possible difference between successive runs of the shuffle() method.
    (...)


    That is not what I meant. To "prove" the sufficiency of OP's shuffle method, you can use any array of 52 unequal elements. It is just that if one uses the ints 0, 1, 2, ... 51, then the test boils down to the simple:
     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:

    A few minutes ago,, I wrote:. . . Unfortunately the first hit on that search uses the wrong algorithm for shuffling. . . .

    I clicked your link again and got a different lot of results, but these two recent hits use the wrong algorithm: 1 2.



    You can use Collections.shuffle() with arrays, you just have to wrap the array in a List first.

    The second algorithm you cited is this:

    If you look at that closely, it's NOT incorrect. I don't see the point of line 4 (although I suspect it's an attempt to "randomize" the random sequence some more, pointless IMO) but the math on line 6 is what's key to understanding the difference between starting at the end vs starting at the beginning.
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:. . . it's NOT incorrect.

    Sorry for my mistake

    I don't see the point of line 4 . . .

    . . . nor of the variable n in line 2: why not use array.length inside the loop.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:Welcome to the Ranch!

    Is that code in shuffle() your implementation or was that provided by your teacher? It's not a very good algorithm. A better way would be to start from the end and iteratively reduce the range of index values you're randomly picking from. That is, pick a random card from [0] to [length -1] and swap it with the card at [length-1]. Then pick another random card from [0] to [length-2] and swap it with the card at [length-2]. Pick from [0] to [length-3] and swap with [length-3] and so on. This ensures that cards you've already randomly picked don't get moved again. In your algorithm, there's a greater chance that cards just get moved back to where they were originally or that they don't get moved at all.



    shuffle() was given to me from my teacher and is also from the book, "Intro to Programming: Java(2nd edition)".  I have a different shuffle code, but I wasn't sure if it was better than what my teacher provided.
    <br /> <br />

    Alternatively, there is an easier and more reliable way: shuffle arrays in Java with Collections.shuffle() although I don't know if you're allowed to use that (I suspect you aren't).

    <br /> Yup, I saw Collections.shuffle() plenty of times online when I was doing my research, but we aren't allowed to use that since my sensei provided me a paper with all the requirements and rules for the program. <br /> <br />

    You can't just use equals() with arrays the way you're doing it. That doesn't work like you think it does because arrays don't override Object.equals(). If you fire up jshell (Java's REPL), you can try this: <br /> <br /> jshell> int[] nums1 = {1, 2, 3, 4} <br /> nums1 ==> int[4] { 1, 2, 3, 4 } <br /> <br /> jshell> int[] nums2 = {1, 2, 3, 4} <br /> nums2 ==> int[4] { 1, 2, 3, 4 } <br /> <br /> jshell> nums1.equals(nums2) <br /> $3 ==> false

    As you can see, even though the two arrays have exactly the same elements, nums1.equals(nums2) still gives you false.

    See java.util.Arrays.equals() and java.util.Arrays.deepEquals()

    jshell> java.util.Arrays.equals(nums1, nums2)
    $4 ==> true



    Oh wow, that makes a lot more sense now... I will try "java.util.Arrays.equals(nums1, nums2)" now and see what happens.

     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:Also, this: "you will need to get the cards before and after the shuffle and count how many are no longer in their original location."

    Your test code is not currently doing that.



    Yeah I know.  I wanted to do the shuffle test first before that part.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Liutauras Vilda wrote:Jon, welcome to the Ranch.

    Also try to give your tests a more descriptive names, so reading them would be instantaneously clear what they are testing. As they are now, I had to look into their implementation to understand what they are actually trying to test.

    For instance this test name:
    testUnshuffled()

    Perhaps would read better as:
    two_unshuffled_decks_are_equal()

    In a similar way also with:
    testShuffled()

    Would read better as:
    unshuffled_and_shuffled_decks_arent_equal()

    Or even more better as:
    unshuffled_deck_after_shuffling_it_is_no_longer_same() (don't know yet how to express an idea that we are talking about the same deck before and after)

    Some suggested more commonly used conventions for naming test methods -> here. I find myself using 4th just separating parts by an underscore _.

    Even initially you got those names not that bad comparing to what I saw once: testingHappyCase(). Try to avoid such and similar naming in the future.

    Note: you don't need to add "test" word to a test method name. Annotation @Test suggests that already. In some cases prefix "test" maybe it makes clearer though, but just be aware of that.




    Oh okay, thanks!  I never knew "test" word in a method name suggests that it is a test... I always thought having "test" in method name was only for naming purposes.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Liutauras Vilda wrote:
    You got that test above. Now, if we'd try to look at each line individually, what line 3 tells you?

    To me it tells a lie. And look how line 4 reads awkwardly, that suggests that something is off. Maybe just naming (by calling it shuffled initially), but then how you'd communicate whether deck is shuffled or not. I'm not entirely sure whether I'm right or not, but I'd explore an opportunity to make method shuffle() to return a new Deck, a shuffled one.

    So you could write:


    And if you start gradually think about it more, you probably can even design Deck along such way:

    So the line 3 now explicitly tells you that the initial Deck you have is unshuffled, because it says so. But writing this test, I kind of see one thing which might be confusing. If we define such static factory method unshuffled() in a Deck class, one would naturally could expect that there is Deck.shuffled(). And maybe that is if you have such concept too. BUT, in such case you'd end up with 2 ways of getting shuffled Deck (get it initially shuffled, or shuffle unshuffled deck):

    [1]
    Deck shuffled = Deck.shuffled();

    [2]
    Deck deck = Deck.unshuffled();
    Deck shuffled = deck.shuffle();

    So you can fall into the trap oof writing test as:

    While actually you'd want to shuffle the same Deck which is initially unshuffled. Sounds confusing probably what I'm at. Could clarify later...



    In Deck.java, technically Deck() is unshuffled right?  
    Because if I write,

    the output would be all the cards unshuffled and in order.

    Idk, it is really confusing for me considering I'm still new.  But, I am trying my best to learn and understand.  Thank you!
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jon Fil wrote:. . . from the book, "Intro to Programming: Java(2nd edition)". . . .

    Please tell us the author of that book.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator


    Here is the paper given to me from my teacher.  I should have included this when I first made the post, I'm very sorry!
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:

    Jon Fil wrote:. . . from the book, "Intro to Programming: Java(2nd edition)". . . .

    Please tell us the author of that book.



    "Introduction to Programming in Java(Second Edition)" by Robert Sedgewick and Kevin Wayne
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:Thank you



    Okay, my mistake.  shuffle() was NOT from the book.  Deck() is what came from the book.
     
    Liutauras Vilda
    Marshal
    Posts: 7264
    492
    Mac OS X VI Editor BSD Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Instructions wrote:Let’s assume that if at least 50% of the cards are not in their original place that the shuffle test passes.  So you will need to get the cards before and after the shuffle and count how many are no longer in their original location.  (Hint: Because arrays are pass-by reference you may find it easy to test this using two different instances of Deck, one shuffled and one un-shuffled)


    That hint actually works as a confusion, I don't to be honest get what it is trying to tell. Could someone please explain?
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I thought it meant to have two copies of the array, one before and one after shuffling, and verify that at least 50% of the cards aren't in their original locations. At least that is what I thought. I think that moving 50%+ of cards is a very weak test; if that doesn't pass, there is something going wrong.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Liutauras Vilda wrote:

    Instructions wrote:Let’s assume that if at least 50% of the cards are not in their original place that the shuffle test passes.  So you will need to get the cards before and after the shuffle and count how many are no longer in their original location.  (Hint: Because arrays are pass-by reference you may find it easy to test this using two different instances of Deck, one shuffled and one un-shuffled)


    That hint actually works as a confusion, I don't to be honest get what it is trying to tell. Could someone please explain?



    I think because
    pass-by-reference = arrays and strings
    pass-by-value = int, char, boolean, and double?


    Idk someone could probably explain better.
     
    Liutauras Vilda
    Marshal
    Posts: 7264
    492
    Mac OS X VI Editor BSD Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:I thought it meant to have two copies of the array, one before and one after shuffling


    I thought that too, but what significance has "Because arrays are pass-by reference you may find it easy". One can pass those arrays in the same way as two primitives would. So really that hint has nothing to do.. with anything actually.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    So do you guys suggest that I should change the shuffle() method?
     
    Liutauras Vilda
    Marshal
    Posts: 7264
    492
    Mac OS X VI Editor BSD Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jon Fil wrote:So do you guys suggest that I should change the shuffle() method?


    Did you verify in the way it is suggested in instructions? Meaning to have 2 decks: 1 unshuffled and 1 shuffled, and so compare the difference how many cards reside in different positions from their originals.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Liutauras Vilda wrote:

    Jon Fil wrote:So do you guys suggest that I should change the shuffle() method?


    Did you verify in the way it is suggested in instructions? Meaning to have 2 decks: 1 unshuffled and 1 shuffled, and so compare the difference how many cards reside in different positions from their originals.



    Have 2 decks in the JUnit test?
    Or 2 decks in Deck class?

     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Java veterans know that the statement "arrays are passed by reference" is misleading at best. All parameters in Java are passed by value, even references to objects, which includes arrays. Always. No exceptions. The hint was written with a specific implementation in mind so I agree that it would be practically useless to anyone who doesn't already know what that implementation is.

    If I were to write the test, I'd do it this way:
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:Java veterans know that the statement "arrays are passed by reference" is misleading at best. All parameters in Java are passed by value, even references to objects, which includes arrays. Always. No exceptions. The hint was written with a specific implementation in mind so I agree that it would be practically useless to anyone who doesn't already know what that implementation is.

    If I were to write the test, I'd do it this way:



    Line 3 is giving me a red squiggly line saying "Type mismatch: cannot convert from void to Deck"
    As well as the 4th line in code below.  

    So you could write:

     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:



    Is this the same as this?
     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Essentially, yes. But shuffled.shuffle() doesn't make a lot of sense semantically, whereas new Deck().shuffle() does. The latter says "create a new Deck and shuffle it."

    To be able to do that, shuffle() would have to return a reference to the Deck itself instead of being declared as a void method. That is, shuffle() would have this line as its last statement:
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:Essentially, yes. But shuffled.shuffle() doesn't make a lot of sense semantically, whereas new Deck().shuffle() does. The latter says "create a new Deck and shuffle it."

    To be able to do that, shuffle() would have to return a reference to the Deck itself instead of being declared as a void method. That is, shuffle() would have this line as its last statement:



    Hmmmm. But what if the UML states that "+shuffle(): void"?
     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sigh. If you must follow the design given to you, then you must. The version you gave works if shuffle() is void, mine won't.
     
    Jon Fil
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Update...
    Please give feedbacks.

    Here is my new test.


    Here's my Deck.java with very minor changes.

     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Your testShuffle() method is not guaranteed to pass every single time. It may pass most of the time but it could still conceivably fail once in a while. You are not testing your shuffle code in the suggested way, i.e., checking that at least half of the cards are not in the original order. Rather, your test requires that NONE of the cards are in their original order.
     
    Campbell Ritchie
    Marshal
    Posts: 66189
    250
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:. . . half of the cards are not in the original order.

    As I said yesterday that is a weak test which is almost certain to pass.

    Rather, your test requires that NONE of the cards are in their original order.

    That is a very strong test, probably far too strong; it is likely that shuffling will replace one card in its original location.
     
    Junilu Lacar
    Marshal
    Posts: 14336
    237
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I take that back. Your test is, in fact, going to pass every single time. However, it will also pass if you comment out the line that shuffles the deck. That is, as you have written it, that test will ALWAYS pass even though the decks being compared are both unshuffled. Try running your test with the line that shuffles deck1 commented out. It will still pass.
     
    Would you like to try a free sample? Today we are featuring tiny ads:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!