Reuse/re-purpose existing steps in your code by using the pipe delimiter.
@Then(“^(I search for and select an existing user|I validate a user has been created)$”)
– Use this sparingly and make your BDD’s more readable.
Author: mrsuvez
I've been a tester since 2006 and absolutely love it!
I believe we should never stop learning, there's so much to know out there!
As a result of that, I love sharing what I learn!
Join me as I explore the software development and testing landscapes.
Working with spring properties and profiles
Today I have a very simple application for you to demonstrate how to use profiles to control environmental variables.
To skip the build and access the code, you can find it here:
https://github.com/suveerprithipal/spring_properties_and_profiles
Lets keep going.
Why do we want this?
So we can swap profiles when testing locally vs a cloud or dev vs test
How do we build this?
Firstly, we need to create an environmental variable. To do so, on windows10,
On windows desktop, Search for “advanced system settings”
Select ‘Advanced system settings’
- Click Environment Variable
- Click “New” under ‘System Variables’
- Set Variable name of ‘APP_URL’
- Set Variable value of ‘cloud’
Next up I created a Maven project and added in my Spring boot dependencies. We then need to create some profiles. Easy peasy. To do so, we actually create properties files. Yep, that simple. Under your java/test filepath, create a resources dir. Remember to right click and mark as ‘test Resources Root’ Create 2 properties files:
- properties-local.properites
- properties-cloud.properties
In each of them, add a variable called ‘my.app.url’ as the following demonstrates.
in properties-local.properites: my.app.url = local
in properties-cloud.properites: my.app.url = ${app_url}
We use “${app_url}” here as we want to point our test to use the system variable we created. When springboot runs, and see’s “${}” it knows to go looking for a definition on that variable on the system.
We’re almost done! and now in a position to add some tests to access these variables we’ve created above.. Create a test or use the one created by default if you have one.
In our test class, create a class member of type ‘Environment'(org.springframework.core.env.Environment). I called mine “env”. Don’t forget to Autowire(org.springframework.beans.factory.annotation.Autowired) this member as we want a bean created for this at run-time.
We create 2 tests:
- localTest
- cloudTest
These are very similar in nature, but have 2 different asserts:
- localTest Assert.assertEquals(“local”, env.getProperty(“my.app.url”));
- cloudTest Assert.assertEquals(“cloud”, env.getProperty(“my.app.url”));
Lastly, we want to specify which profile spring should use when running. To do this, we will add a VM Option to the Run Configuration.
I ran my 2 tests above individually. This create a run configuration for me automatically. I then go to edit these configs.
- localTest Run config: I set the VM option to : -Dspring.profiles.active=local Apply and save.
- cloudTest Run config: I set the VM option to : -Dspring.profiles.active=cloud Apply and save.
Now when we run these, spring will swap out our properties file, based on the profile we selected. You will see that the local env.getProperty will return “local” and cloud env.getProperty will return cloud, which we set on the system.
That’s it! You’re done! Happy Testing.
Functional testing: Numbers vs Coverage
Functional test automation. It’s not entirely about the numbers, but rather the value and coverage of the test you create.
Push left. Cover more in unit/integration tests and less on the UI. Try not to look at this as it takes away from you as a tester’ but rather enhances your ability, exposure and experience.
Its difficult to decide which tests to push left you say?
Yes, I can definitely agree with that. I was hard for me too.
I’ve learnt that this difficulty comes strong at first but when this is a practice we bake into our planning sessions, this becomes easier with time. Communication is the most important influence here. The results of which will lend to a “Team Test Approach” or “Quality mindful team”.
Are you BDDing?
There are many ways in which we can scribe out a feature file. In my experience with teams of various experience, businesses of different maturity and a variety of complexity of applications I have learned there is no 1 way to get this right.
Here are 7 things to remember:
- Don’t just use the tool but use the tool well. Stick to the reasons why we use a ‘Given’, ‘When’ and ‘Then’
- Remove test data setup from your scenarios. If you need to ready your env for test, treat it as a separate concern.
- Tags, tag everything. This is a great way to ensure we run specific tests and deliver faster feedback when you are faced with a time sensitive roll-out.
- A short scenario is a good scenario.
- You scenario’s aren’t cast in stone. Revise and revisit.
- Maturing your BDD is really important. Its living documentation and is ultimately a reflection on our understanding of the application and our drive for high quality applications.
- Share it with your team. Make your team quality conscious. Have them revise it at regular intervals…make it a thing.
Doctor: “we need a WebDriver stat!”
To spin up a WebDriver is pretty easy. We really only need 4 lines of code:
System.setProperty(“webdriver.chrome.driver”,”…”);
WebDriver driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get(“http://…”);
Manual Testing API’s?
For manual testing, Postman is a great resource for API testing. Validate your results post call using their inbuilt test functionality.Here is a link to some test examples.
