We continue to support the exact level of Admin UI testing as we’ve had for the past few major versions of Solr ;-).
Honestly, for the Admin UI, and you won’t love the answer…. “Please start solr from main and solr on my code branch and compare them using Playwrite”. And it works. Even when I can’t figure out how to spell Playwright. Also, with the V2 APIs we get strong typed javascript, so it’s really clear in the console when the generated JavaScript client has changed and the Admin UI hasn’t been updated. It wouldn’t take much to generate a bunch of Admin UI tests, but since that whole UI is not changing much (if any), and we want to move to the new Solr UI, I haven’t seen a strong need to beef up testing, in comparison to other priorities. So yeah, I think in all the places we use the Strong Typed Solr JavaScript client it’s quite obvious. Now, if we start seeing UI bugs starting to crop up, then I would totally agree we need to beef up the testing. > On Aug 13, 2026, at 1:59 PM, Chris Hostetter <[email protected]> wrote: > > > : They are experimental not because they don’t work well, but because we > : want the freedom to improve them. Starting to actually use them is also > : good for confirming the design choices, otherwise we’ll never get any > : actual feedback. Similar to the work to migrate the CLI to using V2 > : apis. > > I think the key queston (and this genuine question from someone out of the > loop) is what kind of automation is in place for testing the UI? > > Because the advantage that comes from freedom to improve the V2 APIs (w/o > heavy consideration of backcompat) becomes a liability if people make big > improvements/changes w/o realizing that doing so breaks the UI. > > if tweaking an API in a way that breaks the UI (or CLI, or SolrJ, etc...) > is something that immediately and obviously causes a test failure, then > that's far less concerning because if the the "client" can be considered a > blocker for that commit. > > > > -Hoss > http://www.lucidworks.com/ <http://www.lucidworks.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
