Carousel rotation testing and validating the products uniqueness using Selenium

Hello There,
Could someone please let me know how can I validate :
1.The uniqueness of the products in a slick carousel?
2.The price of the products in the carousel should be in ascending?

The carousel used in my application is for providing instant gifts to the customers.The gifts are available based on the cart amount
Note that the product attributes are in

tag and the products are active based on the cart price

I have tried to put the carousel elements into a Set and validate the size of the set.I am unable to validate the prices because the values are nbsp.

@konradw @kristof

1 Like

This one sounds like a case of. What are your really testing here, and is there another way you could verify this. I’m going to say, that if I was here, I would test that the number of items in carousel and prices is not a GUI thing at all, but is rather best tested at the API level. and then create a new test case in selenium that just counts that there are the correct number of elements if that is even possible.

My experience is that unless the developer makes it easy for you to “test” the user interface, then they are hurting themselves because they made your job harder and meaning you will take longer to test and longer to raise bugs and thus longer to release. Always ask the web developer if there is another better way to do this. If we are talking about an external website we don’t control, then that’s not really “software-testing” anymore. So use it as an excuse to communicate with the coders. And also use it as a way to break up the UI testing from the business-logic and data-driven parts of the test that might be easier to do in another way or in another tool.


I agree.

So is there a specific price from a certain point that you’ll get a gift?

I’m not sure I quite understand your case but…

You can always try a metamorphic way of testing. It’s where you don’t actually know the outcome (expected outcome) and you validate your tests by the predictions. You compare predictions based on the input and A should be higher then B.


Customer A his cart is 50€
Customer B his cart is 100€
Customer C his cart is 75€

Therefor your expected result of your test is gifts: A < C < B
But you’ll normally do this with 1000+ cases as for 1 test. This might be a bit of overkill and is normally used to test machine learning algorithms.


1.I am just validating if the products that are appearing in the carousel are all unique -->I am doing it by using a HashSet and then checking if the size of the set is the count of the products.
2.I am not bothered about the price of cart
3.For the ascending order of the price of the products I am not clear as to how I need to fetch the price and put it in a collection and then compare as the input values.Attaching the image of the carousel that I need to test.

Is there a room for me to discuss this topic?

1 Like

I remember we had a discussion on google hangouts.Could you please share the link.

It’s a very good question Swetha. You might join us in the live channel if you feel comfortable with that Sign in - Google Accounts . But this is a great forum for questions - I think the problem becomes that all of us need an answer fast on these things, today. Tomorrow always adds yet another test case to implement. and the brick walls like this one are often just a case of needing to break a thing down into smaller pieces.

sometimes you have to step back a long way from a test-case that looks impossible to automate and ask 2 questions.

  1. How likely are the developer to screw this up in future? If not, just write a very simple test that only does 1/4 of the job and then see if that minimal check actualyl catches future regressions.
  2. Can I test this in another place or another way rather. By getting blocked on a check that is unlikely to fail anyway while I could rather be adding testing other areas is not a good use of our time as testers. It’s tough, but sometimes you have to leave the hard bugs for someone else to find.

“I” would take both of these, create a simple test, and create a todo ticket to later on improve this. You might find that 6 months from now the carousel has been changed anyway or that you had a chat with the devs and they fixed your issue for you, or even that you learned a javascript trick or found a tool that lets you do this in 5 minutes.

You could get all the products their names and loop over all the products in the cart to see if it appears again? (or a unique code to the product)

Are you doing this test on UI level? It could be easier on API it seems?

1 Like

Could you please explain how can i do it on API?

This is what I tried:
public boolean validateProducts() throws InterruptedException {
HashSet linkedHashSet = new LinkedHashSet<>();

	 System.out.println("size is :"+linkedHashSet.size());
	for(String i : linkedHashSet) {
	     if(linkedHashSet.size() == 11) {
	    	System.out.println("size is 11 : all are unique products");
	    	 return true; 
		return true;

You’ll POST your products into your cart. Then you probably have an API to get the contents of your CART & gifts in it? You can check on this level if the contents are correct. It will also have prices etc…

It would also remove those nasty sleeps :smiley:

1 Like

1st thing to address is the use of XPATH in test code, moving to CSS ID’s made a huge difference in my test maintainability and ease of maintenance - I found a reasonable guide here

I know this move away from XPATH to CSS selectors is just an incremental suggestion that does not fix things, but it will help longer term because you later need to get rid of sleeps() in the code too, and replacing sleeps with wait() helpers making your code easier to maintain, which is a process in itself. Now I’m not a Web nor an API guru at all (I’m myself an ex-programmer, so I’m really lying about not being a good API tester, but I’m trying to say I have minimal relevant experience in these areas.) And although testing the API as @kristof is pointing out is a brilliant approach, you are probably not ready for maintaining 2 different testing tools. But that should still be a goal to aim for later.

So, back to the product uniqueness problem. it’s really a hard one to solve with just the keys in a hashmap/hash table. I mean it distracts from the real problem to try test for uniqueness, because the hashmap approach would never trip up if the products all came up like this one day:

And this is my main reason for wanting to break this up into multiple tests and even to look at API test tooling on the sideline. But none of this is possible if you the web back-end is not written to be “testable” or easy to test.