Say “no more” to static test data in your tests!

This is how I used to write my tests before I got introduced to faker.

@Test
public void assertThatAPersonCanBeAddedByFillingOnlyMandatoryFields() {
person.setPersonalDetails("", "Yadav", "Pramod", "IN");
person.confirm();

assertWithPersonTable(sqlPerson, "", "Pramod", "Yadav", "IN");
}

Nothing wrong with it, you may say. I follow good design practices, specifically in context of above test:

Except the test…


Information is lost in noise! — ancient wisdom!

Too much of anything is bad.

That was exactly my feeling when I saw these logs time and again, from chrome driver, selenium and mysql thrown at me every single time I ran my tests in parallel.

After a while, I had enough. I started looking into each of these noisy logs and a quick search on stack overflow provided the solution.

Apparently the answer was a two liner solution provided by the curtsy of a few good man here. …


Same tests but two different stories (from mvn and junit)

A wise man, once said, “Tests should be trustworthy, quick and should run at the right time. If not, there is little value in them”

On note of trustworthy, GUI tests are flaky in nature. That’s a reality.

I have worked in backend projects and had zero tolerance for flaky tests. That was until, I had to work in a frontend GUI project.

Now there is flakiness that is purely because of a bad test automation design where say we are not synchronizing our actions enough and which we must strive to get rid of but then there is other…

Pramod Yadav

A learner, creator and mixed automation artist.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store