/**
* Copyright (C) 2022 by Martin Robillard. See https://codesample.info/about.html
*/
package e2.chapter5;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.junit.jupiter.api.Assertions.fail;
import java.util.ArrayList;
import java.util.EmptyStackException;
import java.util.List;
import org.junit.jupiter.api.Test;
public class TestFoundationPile {
private static final Card ACE_CLUBS = Card.get(Rank.ACE, Suit.CLUBS);
private static final Card TWO_CLUBS = Card.get(Rank.TWO, Suit.CLUBS);
private static final Card THREE_CLUBS = Card.get(Rank.THREE, Suit.CLUBS);
private FoundationPile aPile = new FoundationPile();
private int size() {
List<Card> temp = new ArrayList<>();
int size = 0;
while( !aPile.isEmpty() ) {
size++;
temp.add(aPile.pop());
}
while( !temp.isEmpty() ) {
aPile.push(temp.remove(temp.size() - 1));
}
return size;
}
@Test
public void testCanMoveTo_Empty() {
assertTrue(aPile.canMoveTo(ACE_CLUBS));
assertFalse(aPile.canMoveTo(THREE_CLUBS));
}
@Test
public void testCanMoveTo_NotEmptyAndSameSuit() {
aPile.push(ACE_CLUBS);
assertTrue(aPile.canMoveTo(TWO_CLUBS));
assertFalse(aPile.canMoveTo(THREE_CLUBS));
}
@Test
public void
{
assertThrows(EmptyStackException.class, () -> aPile.peek());
}
@Test
public void {
try {
aPile.peek();
();
}
catch(EmptyStackException e )
{}
assertTrue(aPile.isEmpty());
}
@Test
public void testPop_FromTwoToOne() {
aPile.push(ACE_CLUBS);
aPile.push(TWO_CLUBS);
assertEquals(2, size());
assertEquals(TWO_CLUBS, aPile.pop());
assertEquals(1, size());
}
}
By default, JUnit 5 will create a new instance of the test class before running each test method. In practice this means that when a test starts executing, the fields of the test class will hold their initial value, even if other tests change this value. This feature facilitates writing independent tests.
To change the lifecycle behavior of test class, we use the JUnit @TestInstance annotation.
By default, JUnit 5 will create a new instance of the test class before running each test method. In practice this means that when a test starts executing, the fields of the test class will hold their initial value, even if other tests change this value. This feature facilitates writing independent tests.
To change the lifecycle behavior of test class, we use the JUnit @TestInstance annotation.
This test method demonstrates how to use the assertThrows
JUnit5 method to
assert that some code will raise an exception.
This test method demonstrates how to use the assertThrows
JUnit5 method to
assert that some code will raise an exception.
The first argument to assertThrows
is an instance of class Class
that represents
the expected exception type. The second argument is an instance of type
Executable
whose implementation of the corresponding execute()
method is expected to throw the exception.
Here we used a lambda expression to create the required instance. Lambda expressions are
covered in detail in Chapter 9.
The first argument to assertThrows
is an instance of class Class
that represents
the expected exception type. The second argument is an instance of type
Executable
whose implementation of the corresponding execute()
method is expected to throw the exception.
Here we used a lambda expression to create the required instance. Lambda expressions are
covered in detail in Chapter 9.
This test method demonstrates how to use the try/fail pattern to assert that some code will raise an exception.
This test method demonstrates how to use the try/fail pattern to assert that some code will raise an exception.
List
interface. Implements all optional list operations, and permits all elements, including null
. In addition to implementing the List
interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector
, except that it is unsynchronized.)
List
interface. Implements all optional list operations, and permits all elements, including null
. In addition to implementing the List
interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector
, except that it is unsynchronized.)
The size
, isEmpty
, get
, set
, iterator
, and listIterator
operations run in constant time. The add
operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList
implementation.
Each ArrayList
instance has a capacity. The capacity is the size of the array used to store the elements in the list. It is always at least as large as the list size. As elements are added to an ArrayList, its capacity grows automatically. The details of the growth policy are not specified beyond the fact that adding an element has constant amortized time cost.
An application can increase the capacity of an ArrayList
instance before adding a large number of elements using the ensureCapacity
operation. This may reduce the amount of incremental reallocation.
Note that this implementation is not synchronized. If multiple threads access an ArrayList
instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList
method. This is best done at creation time, to prevent accidental unsynchronized access to the list:
List list = Collections.synchronizedList(new ArrayList(...));
The iterators returned by this class's iterator
and listIterator
methods are fail-fast: if the list is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove
or add
methods, the iterator will throw a ConcurrentModificationException
. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException
on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
This class is a member of the Java Collections Framework.
Explicitly fail the test if the execution reaches this point. The logic is that, if the execution reaches this point, it's because no exception was thrown, and thus the code did not execute as expected.
Explicitly fail the test if the execution reaches this point. The logic is that, if the execution reaches this point, it's because no exception was thrown, and thus the code did not execute as expected.
Although failing with an explicit failure message is recommended, this method may be useful when maintaining legacy code.
See Javadoc for fail(String)
for an explanation of this method's generic return type V
.
This part of the test class is the scaffolding, which can be used by all tests.
Chapter 5, insight #8
Use test fixtures to structure your testing code cleanly. Remember that any data used by unit tests must be initialized before every test, since tests are not guaranteed to be executed in any specific order
This part of the test class is the scaffolding, which can be used by all tests.
Chapter 5, insight #8
Use test fixtures to structure your testing code cleanly. Remember that any data used by unit tests must be initialized before every test, since tests are not guaranteed to be executed in any specific order
This method is an example of a helper method that obtains information about the state of the object under test without using reflection.
Chapter 5, insight #11
Do not weaken the interface of a class only to provide additional state inspection methods for your tests. Instead, write helper methods in the test class to obtain this information.
This method is an example of a helper method that obtains information about the state of the object under test without using reflection.
Chapter 5, insight #11
Do not weaken the interface of a class only to provide additional state inspection methods for your tests. Instead, write helper methods in the test class to obtain this information.
Chapter 5, insight #2
Design your unit tests so that they are focused, that is, that they isolate and test a small and well-defined amount of behavior
Chapter 5, insight #2
Design your unit tests so that they are focused, that is, that they isolate and test a small and well-defined amount of behavior
Unlike sets, lists typically allow duplicate elements. More formally, lists typically allow pairs of elements e1
and e2
such that e1.equals(e2)
, and they typically allow multiple null elements if they allow null elements at all. It is not inconceivable that someone might wish to implement a list that prohibits duplicates, by throwing runtime exceptions when the user attempts to insert them, but we expect this usage to be rare.
The List
interface places additional stipulations, beyond those specified in the Collection
interface, on the contracts of the iterator
, add
, remove
, equals
, and hashCode
methods. Declarations for other inherited methods are also included here for convenience.
The List
interface provides four methods for positional (indexed) access to list elements. Lists (like Java arrays) are zero based. Note that these operations may execute in time proportional to the index value for some implementations (the LinkedList
class, for example). Thus, iterating over the elements in a list is typically preferable to indexing through it if the caller does not know the implementation.
The List
interface provides a special iterator, called a ListIterator
, that allows element insertion and replacement, and bidirectional access in addition to the normal operations that the Iterator
interface provides. A method is provided to obtain a list iterator that starts at a specified position in the list.
The List
interface provides two methods to search for a specified object. From a performance standpoint, these methods should be used with caution. In many implementations they will perform costly linear searches.
The List
interface provides two methods to efficiently insert and remove multiple elements at an arbitrary point in the list.
Note: While it is permissible for lists to contain themselves as elements, extreme caution is advised: the equals
and hashCode
methods are no longer well defined on such a list.
Some list implementations have restrictions on the elements that they may contain. For example, some implementations prohibit null elements, and some have restrictions on the types of their elements. Attempting to add an ineligible element throws an unchecked exception, typically NullPointerException
or ClassCastException
. Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter. More generally, attempting an operation on an ineligible element whose completion would not result in the insertion of an ineligible element into the list may throw an exception or it may succeed, at the option of the implementation. Such exceptions are marked as "optional" in the specification for this interface.
The List.of
and List.copyOf
static factory methods provide a convenient way to create unmodifiable lists. The List
instances created by these methods have the following characteristics:
UnsupportedOperationException
to be thrown. However, if the contained elements are themselves mutable, this may cause the List's contents to appear to change. null
elements. Attempts to create them with null
elements result in NullPointerException
. subList
views implement the RandomAccess
interface. This interface is a member of the Java Collections Framework.
true
if this list contains no elements.
true
if this list contains no elements.
isEmpty
in interface Collection<E>
true
if this list contains no elements
Stack
class to indicate that the stack is empty.
Stack
class to indicate that the stack is empty.
Integer.MAX_VALUE
elements, returns Integer.MAX_VALUE
.
Integer.MAX_VALUE
elements, returns Integer.MAX_VALUE
.
size
in interface Collection<E>
index
- the index of the element to be removed
UnsupportedOperationException
- if the remove
operation is not supported by this list
IndexOutOfBoundsException
- if the index is out of range (index < 0 || index >= size()
)
expected
and actual
are equal.
Lists that support this operation may place limitations on what elements may be added to this list. In particular, some lists will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. List classes should clearly specify in their documentation any restrictions on what elements may be added.
add
in interface Collection<E>
e
- element to be appended to this list
true
(as specified by Collection.add(E)
)
UnsupportedOperationException
- if the add
operation is not supported by this list
ClassCastException
- if the class of the specified element prevents it from being added to this list
NullPointerException
- if the specified element is null and this list does not permit null elements
IllegalArgumentException
- if some property of this element prevents it from being added to this list
@Test
is used to signal that the annotated method is a test method.
@Test
is used to signal that the annotated method is a test method.
@Test
methods must not be private
or static
and must not return a value.
@Test
methods may optionally declare parameters to be resolved by ParameterResolvers
.
@Test
may also be used as a meta-annotation in order to create a custom composed annotation that inherits the semantics of @Test
.
@Test
methods are inherited from superclasses as long as they are not overridden according to the visibility rules of the Java language. Similarly, @Test
methods declared as interface default methods are inherited as long as they are not overridden.
By default, test methods will be ordered using an algorithm that is deterministic but intentionally nonobvious. This ensures that subsequent runs of a test suite execute test methods in the same order, thereby allowing for repeatable builds. In this context, a test method is any instance method that is directly annotated or meta-annotated with @Test
, @RepeatedTest
, @ParameterizedTest
, @TestFactory
, or @TestTemplate
.
Although true unit tests typically should not rely on the order in which they are executed, there are times when it is necessary to enforce a specific test method execution order — for example, when writing integration tests or functional tests where the sequence of the tests is important, especially in conjunction with @TestInstance(Lifecycle.PER_CLASS)
.
To control the order in which test methods are executed, annotate your test class or test interface with @TestMethodOrder
and specify the desired MethodOrderer
implementation.
condition
is true
.
condition
is false
.
executable
throws an exception of the expectedType
and return the exception.
executable
throws an exception of the expectedType
and return the exception.
The assertion passes if the thrown exception type is the same as expectedType
or a subtype thereof. To check for the exact thrown type use assertThrowsExactly
. If no exception is thrown, or if an exception of a different type is thrown, this method will fail.
If you do not want to perform additional checks on the exception instance, ignore the return value.
expected
and actual
are equal.