Skip to main content

Junit parameterization - the next step

Background
I have just been fooling around with Junit's parameterization support. Here is what I learned so far
JUnit 4 has support for parameterization. In short, write test points, and run them for different parameters.

for eg.

The Test point could be
test() { launch browser for (browsername); }
and it needs to be run for multiple browsers.

The Parameter here is the 'browsername'.

JUnit allows you to define a @Parameters decorated method (with any name) which you use to define what the list of browser names are. Of course, you can even have multiple parameters (which is why the weird List of array syntax appears)

Thus, if you want to run launchbrowser() with 'ie', 'firefox', 'chrome', you write (Note: you need to add @RunWith(Parameterized.class). See Junit4 doc for details.



@RunWith(Parameterized.class)
public class myTest {

@Parameters
public static Collection mybrowsers() {
// Return a collection of string[]'s here
// Weird that JUnit requires this format, but it seems to be for good reason
return new List{new String{}["ie"], new String[]{"firefox"}};
}

// Constructor needs to contain your parameters (browser name only in this case)
public myTest(String browsername) {
  this.browser = browsername;
}

// a real test
@Test
public void launchbrowser(){
   launch(this.browser);
}
}



Now what?
I would next like to take this a step further. I want a base class that contains my parameterization. I want my actual test classes to not worry about that, and simply write tests that will be automatically parameterized. Classic example, a file i/o api, that needs to be tested for a text file, binary file, remote file, local file etc

I can have several classes defined to hold my parameterization, then at authoring time, I pick one to inherit from, depending on what I want to parameterize my tests on. Alternatively, you can also define multiple parameters.

One approach is:

TestA,TestB <--- BaseClassA
TestC <--- BaseClassB

Another is TestA, TestB, TestC <-- BaseClassWithMultipleParameters

Approach 2 has advantage of code reuse, but this may not be what you always want.

What does this achieve?
My Test Classes simply extend from BaseClassA or B, but don't have any parameterization code. I can then create a no. of subclasses that all get the parameterization for free! The consumer test classes don't even have to explicitly know their tests are being parameterized!

I am just beginning to give this some thought. Perhaps there are better ways to do this.

I would mainly like to get rid of the inheritance model.


More on this later...
Labels:

Comments

Post a Comment

Popular posts from this blog

Authenticating Spring Boot based application against secure LDAP/AD server

Authenticating against an Active Directory setup is quite common in organizations using Spring Boot / Spring Security can be a pain if you don't know exactly the requirements. I needed to add auth in my web app and secure some but not all endpoints of the application. My story was, I needed Spring security to authenticate against my company LDAP server which uses Active Directory I started by using the standard LDAP guide such as this which are all over the Internet, https://spring.io/guides/gs/authenticating-ldap/ and was able to setup the basic framework However, only test level LDAP auth was working for me, when I tried to auth against the company LDAP secure server, I had to resolve a few issues After 1 week and working with several devs at the company, I finally found why it was not working and the fix was easy Since I spent a week or so resolving this, I wanted to write this up in case someone finds this useful. Here is what I did (it was easy until the fourth ...
Post a Comment
Read more

Using custom conditional logic to enable/disable Spring components

If you have a Spring component and you don't want it to load, you can use Spring's predefined conditionals as much as possible. For example, @Component   @ConditionalOnNotWebApplication   public class SchedulerEntryPoint implements ApplicationRunner { ...  } This will not load your component when running in non web application mode. Such as you may want to start the application but without any of the web framework using SpringApplicationBuilder. But sometimes you want to use custom conditions. It's pretty easy to do so, just use something like this @Component @Conditional (SchedulerCheck. class ) public class SchedulerEntryPoint implements ApplicationRunner { public static class SchedulerCheck implements Condition { @Override public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) { return System. getProperty ( "scheduler" ) != ...
Post a Comment
Read more

Sending Form data to a backend REST API using Axios

This need is incredibly common and useful, and hopefully will save you a lot of time when doing server side calls from your UI application (or even non UI clients like NodeJS applications) Example here is to send a POST request to an endoint /api/item/new (which will create a new item in the database). We will just assume tbhe backend is already setup (it's not relevant to this article). All we need to know is that we can do a POST /api/item/new and send it form data with two pieces of info     name, filter So, if you have a node.js application (I was using Vue-cli generated project, but it does not matter), install 'axios' (a most popular tool to make server calls these days) npm i axios --save OR yarn add axios (my preferred method) Now, in your service JS file (which is generally when I keep all my api calls) do something like this createNew ( name , filter ) { let formData = new FormData (); formData . append ( "name" , ...
Post a Comment
Read more