Regarding writing tests, some developers are lazy writing fewer test scenarios as possible. And sometimes they can write no scenarios at all. Imagine being able to test many scenarios without writing much code. Isn\u2019t that great?<\/p>\n\n\n\n
A parameterized test lets you test many scenarios. You just send a list of parameters. This way, you don\u2019t need to write many test methods.<\/p>\n\n\n\n
Normally our test methods don\u2019t receive any parameters at all. Because we won\u2019t call them directly, JUnit calls them for us when we run the tests. With parameterized tests, you can use a list of parameters in your test.<\/p>\n\n\n\n
JUnit will iterate through that list calling our test method for each element in it.<\/p>\n\n\n\n
That\u2019s the beauty of this feature. You can increase your test scenarios by only growing the parameter list. No need to write another method to test each different value.<\/p>\n\n\n\n
This feature lets you use parameters from various sources in your tests. Here are some examples:<\/p>\n\n\n\n
And much more. You can even combine two sources. You can check all possible ways in the JUnit documentation. This can vary from version to version.<\/p>\n\n\n\n
So let\u2019s go to the fun part. I\u2019ll combine this with the boundary testing technique<\/a> I shared in another post to apply this. If you didn\u2019t read it, don\u2019t worry, I\u2019ll summarize it for you. It consists of testing the borders of your code where it\u2019s most likely that bugs arise. To apply this technique you can follow these steps:<\/p>\n\n\n\n Let\u2019s take this password validation as an example:<\/p>\n\n\n We can break it down to identify the partitions, and what the boundaries will be:<\/p>\n\n\n\n Now we can write a parameterized test to help simply achieve this. We started creating a source of data to test. Like said before it can be CSV, Method, Enum, etc. In this case, we\u2019re going to use the Now we create a method of arguments (input, and expected value) that will be passed to our test method:<\/p>\n\n\n Then we create a simple See, a straightforward test case, that will test all boundary scenarios of our code. To add more tests for this method, add a line of input and expected values in the boundaries source method. You won\u2019t need to create more test methods.<\/p>\n\n\n\n In this post, you learned a way to write more tests without adding too much code to your tests. Parameterized tests easily add extra scenarios. This ensures everything is okay<\/p>\n\n\n\n Now it\u2019s your turn, to look at your code, and see which places in your code you can start using some parameterized tests. Use this with boundary tests. Your code and tests will be more reliable.<\/p>\n\n\n\n Don\u2019t forget to follow me on social media to be the first to read when my next article comes out!<\/p>\n\n\n\n Willian Moya (@WillianFMoya) \/ X (twitter.com)<\/a><\/p>\n\n\n\n\n
\npublic static boolean validatePassword(String password) {\n if (password == null || password.length() < 8 || password.length() > 20) {\n return false;\n }\n return true;\n}\n\n<\/pre><\/div>\n\n\n\n
\n
\n
\n
\n
\n
MethodSource<\/code>.<\/p>\n\n\n\n\npublic static Stream<Arguments> boundaries() {\n return Stream.of(\n Arguments.of(null, false), \/\/ null value\n Arguments.of("1234567", false), \/\/minimum - 1\n Arguments.of("12345678", true), \/\/ exact minimum\n Arguments.of("123456789", true), \/\/ minimum + 1\n Arguments.of("123456789012345678", true), \/\/ maximum - 1\n Arguments.of("1234567890123456789", true), \/\/ exact maximum\n Arguments.of("123456789012345678901", false) \/\/ maximum + 1\n );\n}\n\n<\/pre><\/div>\n\n\n@ParametizedTest<\/code>that will exercise all the scenarios described above:<\/p>\n\n\n\n@ParameterizedTest\n@MethodSource("boundaries")\nvoid validatePassword(String password, boolean expected) {\n assertEquals(expected, PasswordValidator.validatePassword(password));\n}\n\n<\/pre><\/div>\n\n\nConclusion<\/h2>\n\n\n\n