Spent a wet weekend indoors and decided to spin up a testing framework. Here is my top 11.
What’s in it?
Java 8 Maven Spring Application. + Cucumber + Selenium + Restful API Test Automation Framework + Postgres + Spring JPA. This setup included :
- Restful Api call and testing using RestTemplates and a Pojo for modelling the Json.
- BDD with Cucumber for Feature
- Postgres Db
- Spring JPA
- Swagger Api Documentation
- Rest Assured
- Page Object Modelling
- Saucelabs integration
- Tomcat – Standard with Spring
What else should I add in here?
Here is a java maven spring application for unit and integration testing.
This example uses JUnit, hamcrest and mockito for writing unit tests and doing a bit of tdd.
Here is another sample test app that uses Cucumber as well as Rest Assured to test a rest call that is being mocked.
All this being driven from the cucumber feature file. In this example, we use rest templates to make a call and validate it JUnit. We also use a 1-liner with rest-assured to do the same test.
A gain in response time while functional front-end testing is like striking oil in your backyard.
Here I used Selenide Page Object Models and Junit to fire up a chrome browser test under 10 seconds.
Ok, its not actually a word but an acronym.
In “The Dependency Inversion Principle” (or DIP), the author states the three defining factors of “bad code”:
- It is hard to change because every change affects too many other parts of the system (Rigidity)
- When you make a change, unexpected parts of the system break (Fragility)
- It is hard to reuse in another application because it cannot be disentangled from the current application(Immobility)
- Json Jackson
- Json Simple
- Junit 4
- Junit 5
- Java 8 Lambda
An example showcasing junit 5 jupiter in a springboot maven project. I hope ya’ll had a good good weekend! I had fun’ed some, I learnt some and I built this little monster here.
Many a times in test automation we rarely talk about the importance of goodie good Jenkins Server management.
I tell ya, I spent a week putting out fires! Im a little weird so I found it exhilarating :$ but it caused a lot of jobs not to be run, therefore proving lesser confidence in tests and applications <– terrible!
Here are some lessons learned :
- Expire and Clean up old builds – yes, check that box!
- Dont schedule jobs with unapproved scripts.
- Parallel runs … always parallel runs.
- Create a uniformed approach to building jobs.
- Create policies to guide and govern the above.
- Set reminds to go back and clean out logs, files, builds etc.
- Always(Ok most of the time) run Jenkins in a Master/Salve config
Share some of your ideas below for me to learn off!