That sounds good. And, from a quick look, the Asciidoc screenshot tool uses Geb, which uses Selenium as well (WebDriver anyway). So, maybe there is a clear path somewhere in there.
Regards, Alex. On 2 August 2018 at 19:01, Jan Høydahl <jan....@cominvent.com> wrote: > Neither though I think will get a collection into the correct pre-populated > state > > > We already have JUnit, so we could write a new test suite for UI testing, > perhaps > one that is not run by default, but has its own ant targer? Using JUnit we > can > pre-populate Solr clusters. The SolrUITestBase class could have conveience > methods to create collections, feed example docs etc. > > Then, using Selenium webdriver as part of a JUnit test, we can navigate to > the > exact location in the UI we need, asserting various things along the way, > and > finally we can do screenshots of the whole page or limited to a CSS > selector. > See http://www.baeldung.com/java-selenium-with-junit-and-testng > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 2. aug. 2018 kl. 16:15 skrev Alexandre Rafalovitch <arafa...@gmail.com>: > > +1 as I think it would open up other example/documentation options. > > Chrome driver by itself may be sufficient for just sample screenshots, > but Selenium may be better for testing and more advanced use-cases. > Neither though I think will get a collection into the correct > pre-populated state. So that would still need to be figured out (maybe > something like Postman: https://www.getpostman.com/postman ). > > I think it would also go hand-in-hand with improving examples, so the > screenshots are taken of something users could also use/reproduce. > And/or with longer "getting started" example that could be automated > with screenshots along the way. > > Regards, > Alex. > > On 2 August 2018 at 06:37, Jan Høydahl <jan....@cominvent.com> wrote: > > In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This > affects pretty much > all admin UI screenshots in the Reference Guide, so the next question then > is "How do we > keep all those screenshots up to date?". I counted a total of 42 screen > shots of the UI, many > which require creating collections, adding data, typing things into the UI > etc up front. > > Due to the work involved, we often tend to update only a few shots and leave > others as-is even > if they are inaccurate. Example is the new "Suggestions" menu tab - there > are 27 screen > shots in the ref guide which are not updated with that menu option. > > For SOLR-12613 I'm tempted to only update the four images in "cloud-screens" > folder for now. > > Perhaps for the future an automated approach can be taken using Selenium, as > outlined in > this post: > https://blog.codeship.com/automating-screenshots-in-documentation/ This > could > in first phase be a standalone tool to generate screenshots but could also > be extended with > other tests to get some validation of the UI itself, which is completely > lacking today. WDYT? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
