Happy 2021, everyone!
I'd like to wish everyone a great start to an even greater new year!
In keeping with tradition, here's one last look back at fahd.blog in 2020.
During 2020, I posted 10 new entries on fahd.blog. I am also thrilled that I have more readers from all over the world! Thanks for reading and especially for giving feedback.
Top 3 posts of 2020:I'm going to be writing a lot more this year, so stay tuned for more great techie tips, tricks and hacks! :)
Related posts:A parameterized test allows you to run a test against a varying set of data. If you find yourself calling the same test but with different inputs, over and over again, a parameterized test would help make your code cleaner. To create one in JUnit 5 you need to:
@ParameterizedTest@ValueSourceThe sections below describe some of the commonly used source annotations you can use to provide inputs to your test methods.
@ValueSource
This annotation lets you specify a single array of literal values that will be passed to your test method one by one, as shown in the example below:
@ParameterizedTest
@ValueSource(ints = {2, 4, 6})
void testIsEven(final int i) {
assertTrue(i % 2 == 0);
}
@CsvSource
This annotation allows you to specify an array of comma-separated values, which is useful if your test method takes multiple arguments. If you have a large number of arguments, you can use an ArgumentsAccessor to extract the arguments as opposed to creating a method with a long parameter list. For example:
@ParameterizedTest(name = "Person with name {0} and age {1}")
@CsvSource({ "Alice, 28",
"Bob, 30" })
void testPerson(final String name, final int age) {
final Person p = new Person(name, age);
assertThat(p.getName(), is(name));
assertThat(p.getAge(), is(age));
}
@ParameterizedTest(name = "Person with name {0} and age {1}")
@CsvSource({ "Alice, 28",
"Bob, 30" })
void testPersonWithArgumentAccessor(final ArgumentsAccessor arguments) {
final String name = arguments.getString(0);
final int age = arguments.getInteger(1);
final Person p = new Person(name, age);
assertThat(p.getName(), is(name));
assertThat(p.getAge(), is(age));
}
By the way, note how I have also customised the display name of the test using the {0} and {1} argument placeholders.
@CsvFileSource
This annotation is similar to CsvSource but allows you to load your test inputs from a CSV file on the classpath. For example:
@ParameterizedTest(name = "Person with name {0} and age {1}")
@CsvFileSource(resources = { "data.csv" })
void testPerson(final String name, final int age) {
final Person p = new Person(name, age);
assertThat(p.getName(), is(name));
assertThat(p.getAge(), is(age));
}
@MethodSource
This annotation allows you to specify a factory method which returns a stream of objects to be passed to your test method. If your test method has multiple arguments, your factory method should return a stream of Arguments instances as shown in the example below:
import static org.junit.jupiter.params.provider.Arguments.*;
@ParameterizedTest(name = "{0} is sorted to {1}")
@MethodSource("dataProvider")
void testSort(final int[] input, final int[] expected) {
Arrays.sort(input);
assertArrayEquals(expected, input);
}
static Stream<Arguments> dataProvider() {
return Stream.of(
arguments(new int[] { 1, 2, 3 }, new int[] { 1, 2, 3 }),
arguments(new int[] { 3, 2, 1 }, new int[] { 1, 2, 3 }),
arguments(new int[] { 5, 5, 5 }, new int[] { 5, 5, 5 }));
}
For more information, see the JUnit 5 User Guide on Parameterized Tests.
If you're still on JUnit 4 (why?!), check out my previous post on Parameterized Tests in JUnit 4.
Large tables can be compressed in Kdb+ by setting .z.zd. Compression of data can reduce disk cost and in some cases even improve performance for applications that have fast CPUs but slow disks.
.z.zd is a list of three integers consisting of logical block size, algorithm (0=none, 1=q, 2=gzip, 3=snappy, 4=lz4hc) and compression level.
Here is an example showing how to compress a table:
// Helper function that sets .z.zd and
// returns the previous value of .z.zd
.util.setZzd:{
origZzd:$[count key `.z.zd;.z.zd;()];
if[x~();
system"x .z.zd";
:origZzd;
];
.z.zd:x;
origZzd}
// create a table
td:([]a:1000000?10; b:1000000?10; c:1000000?10);
// save the table to disk without compression
`:uncompressed set td;
// save the table to disk using q IPC compression
origZzd:.util.setZzd[(17;1;0)];
`:compressed set td;
.util.setZzd[origZzd];
You can check compression stats by using the -21! function:
q)-21!`:compressed compressedLength | 5747890 uncompressedLength| 24000041 algorithm | 1i logicalBlockSize | 17i zipLevel | 0i
The size of the file on disk is reduced from 22.8 MB to 5.5 MB after using q IPC compression.
This post shows how to test for expected exceptions using JUnit 5. If you're still on JUnit 4, please check out my previous post.
Let's start with the following class that we wish to test:
public class Person {
private final String name;
private final int age;
/**
* Creates a person with the specified name and age.
*
* @param name the name
* @param age the age
* @throws IllegalArgumentException if the age is not greater than zero
*/
public Person(String name, int age) {
this.name = name;
this.age = age;
if (age <= 0) {
throw new IllegalArgumentException("Invalid age:" + age);
}
}
}
To test that an IllegalArgumentException is thrown if the age of the person is less than zero, you should use JUnit 5's assertThrows as shown below:
import static org.hamcrest.CoreMatchers.*;
import static org.hamcrest.MatcherAssert.*;
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
class PersonTest {
@Test
void testExpectedException() {
assertThrows(IllegalArgumentException.class, () -> {
new Person("Joe", -1);
});
}
@Test
void testExpectedExceptionMessage() {
final Exception e = assertThrows(IllegalArgumentException.class, () -> {
new Person("Joe", -1);
});
assertThat(e.getMessage(), containsString("Invalid age"));
}
}
Related post: Testing Expected Exceptions with JUnit 4 Rules
Java 15 introduces Sealed Classes, a preview language feature, that allows classes/interfaces to restrict which other classes/interfaces may extend or implement them. Here is an example:
public sealed class Vehicle permits Car, Truck, Motorcycle { ... }
final class Car extends Vehicle { ... }
final class Truck extends Vehicle { ... }
final class Motorcycle extends Vehicle { ... }
In the example above, Vehicle is a sealed class, which specifies three permitted subclasses; Car, Truck and Motorcycle.
The subclasses must be:
permits clause is not required because the compiler will infer them from the declarations in the file.final (i.e. cannot be extended further), sealed (i.e. permit further subclasses in a restricted fashion) or non-sealed (i.e. open for extension by any class).Sealing serves two main purposes:
Vehicle (so no default clause is needed) and it will also give an error if any of them are missing:
int doSomething(Vehicle v) {
return switch (v) {
case Car c -> ...
case Truck t -> ...
case Motorcycle m -> ...
};
}