> 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 <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 >
