Ambiguous FluentList / FluentWebElement

[nedtwigg]

I'm new to FluentLenium, so I might be missing something.

FluentList has a bunch of methods that make it look like a FluentWebElement by delegating to the first element. e.g. name(), text().

Generally, I presume that when the user is calling one of these, they are expecting that the list actually only contains one element anyway. It would be a lot safer if these convenience methods didn't exist, and there were instead a method like E single() which either returns the one and only element in the list or throws an error.

Is there a method along the lines of single() that I'm missing?

[Toilal]

There's no such method, but it could be implemented for sure, it's a good idea ☺️.

[filipcynarski]

You can use first or last instead

I have removed all ambiguous methods which were returning first element

[nedtwigg]

Looks like there's still no single though, correct? Very often, I expect there to be only a single element in the collection, and it would be great to be able to express that assertion concisely though single, rather than assertSize == 1, then first.

[filipcynarski]

Ok makes sense to me, I'll reopen this task according to your suggestion

[filipcynarski]

@nedtwigg single method added and merged to develop branch

[jlannoy]

Hello all.

Today I wanted to update from 3.4.1 to 3.6.1... But hundreds of lines are not compiling anymore. In fact, by resolving this issue, you deleted all what you consider as ambiguous methods.

But these methods were not so ambiguous. As the selector allows you to specify a lot of different approaches, you can directly point to one specific element. Writing $("#my-element").text() seems a correct way of coding, while $("#my-element").single().text() is superfluous. Especially as the single one assumption could have been automated and not forced through a new method to add in our code. I mean, by doing $("#my-element").text(), it's clear that I'm waiting only one element, so the check could have been hidden by encapsulating the newsingle() in each related method. I think it would have been nicer.

That's one FL user opinion, but even if you don't agree you could at least have left those methods available, but deprecated, with an explanation. Please note that even the documentation still explain that way of working (under "Information" paragraph).

Regards,

Jonathan

[filipcynarski]

Thank you Jonathan for the information, the methods were deprecated I think for some time but we finally rid these methods out. My personal opinion using lists when you expect one element doesn't make sense and it is better to use el instead of $ that's why we decided to remove the methods which may blow up if the list size greater then 1. I know somebody might rely on the logic before, we can add the deprecated methods back, but it is real issue for you now?

In terms of documentation the FluentLenium team is bigger starting this month, so we are working on better documentation and code quality :)

Please let me know what are you thinking about FluentList features, have a good day!

[jlannoy]

Hi Filip.

I did never pay attention to the el but it make sense :)

It's not an issue for me not to be on the last Fluent version, I don't think I would have commented the issue, but let me explain the context. I'm an active contributor of Ninja Framework, which proposes FluentLenium in it's stack. Some days ago I proposed a PR with a upgrade of a lot of dependencies. Discovering some FL methods disappeared, I decided not to upgrade the framework to the last version. It could represent too much unwanted work for the framework users, for quite a small update. I'll wait a higher version to do it and document the "how to update" page according to that. The problem on the other hand on our open source projects is "when can I delete such deprecated methods?".

PS : I'll try in my own project to brute replace $() with el() ;)

[filipcynarski]

@jlannoy FluentLenium was massively changed last year so the version 3 in comparison to 2 is totally different. It was basing on real experience related to mine and @Toilal case. We are working in companies with a huge sets of Selenium tests and complex software examining by such tests. So the project is tested by real users :) Please let me know what you need now or what we need to change/improve to help you working with FluentLenium

[jlannoy]

@filipcynarski I don't understand the sense of your answer... We are using FL on production projects with big sets of tests too. Through the use of NinjaFramework, but it doesn't change the fact that I'm giving you real user experience... Even more, it's because I think that there will be other real users surprised that I'm telling you.

I'm sorry to tell again, but going from 3.4.1 to 3.6.1 (not 2.x to 3.x, which I would have understood) should not lead to disappeared methods but deprecated ones (I've checked, they were not, never). Such an update should be a minimum backward compatible for users, or at least not time-consuming. Especially methods that are still shown as examples in the documentation. It's not a big issue, I'm just warning you to keep in mind that when you delete something, other real users can be affected.

Btw, you can close the issue ; we will simply update later. For the NinjaFramework I'll document clearly the changelog for a next version. Thank you for your time.

[filipcynarski]

Sorry I had to miss the point you faced the issue on the same version. Thank you for pointing this out. We will keep in mind that such changes may affect a lot of users.