Introduction to Multilingual Retrieval Augmented Generation (RAG)
Browser based testing
1. Pitfalls and tips withPitfalls and tips with
browser based testIngbrowser based testIng
2. My Background
several projects with functional testing
consulted at organizations to introduce functional testing
and builds
heavily involved in trying to improve effectiveness and
reduce maintenance
developed a framework over several projects that made use
of my learnings
3. Common uses of functional
tests
smoke/sanity tests for most valuable and risky features
black box/regression tests
post deployment checks and rollbacks
multi browser testing
4. what do we want from
tests?
correctness (when my tests work, my application is not
broken)
robustness (when my tests break, my application is broken)
5. what do we focus on?
what’s valuable? (it matters to us that people can do this)
what’s risky? (if this breaks, it really affects us)
29. what happens
there is an initial stream of tests
tests break unnecessarily
tests become hard to maintain
team loses confidence and motivation
some teams even abandon testing via the UI
not knowing the tool
not understanding what works and what doesnt
there are many things you can do to speed up tests, but you have to care about it
1) yes test code is less valuable than production code
2) but production code is less valuable than the product too
3) we are only as good as our tools allow us to be
4) similar rules apply as technical debt -> grows exponentially
1) avoid a specialist
2) people are aware of testability when designing UI
3) tests are written by people who best know that section of the domain.
ruby/java community does a lot around testing
testing domain benefits a lot from dsls
I believe ruby is a very powerful language anyway
mechanize
copybara
1) it generates some fairly bad code
2) you’ll get really fast anyway
webrat is an example of an existing tool like this
allows you to use mechanize, copybara for most tests
allows you to switch to webdriver/sahi/wati which are at times faster
smoke, high value, high risk, per feature
highly recommended
if you dont like object, read encapsulation
we used cucumber, not a big fan so far
don’t recommend this right away
but be aware you might want to do this someday
tests are parallelizable
tests are parallelizable
expose apis
jump straight to pages
assert stuff in the database or from services
insert admin settings directly
jump straight to pages
assert stuff in the database or from services
insert admin settings directly
even if its valuable, dont check it on every test
still use test flows
per feature
“it depends”
fast selectors (dont worry most of the time)
I prefer xpath
css selectors considered more readable
semantic markup is your friend
on missing elemnts
but may not be an assertion failures
