Frank comes with a set of predefined steps that you can use right away
to start scripting your tests. They are a good way to play around with
Frank and see if it would be a good fit for your team. They are also a
good way to automate short lived, tedious tasks in the app, such as
recreating a complex setup before starting some exploratoratory
testing, or documenting the exact steps that need to be taken to
recreate a defect.
If you start to build a large suite of tests using these steps in
your feature files you will quickly find that they are trouble to
maintain and can be brittle depending on how much your UI is changing.
You’ll be much better off if you write your own steps
which communicate the language of your specific domain.
There used to be a similar set of steps for testing web applications
in that came along with the default cucumber install but they were
removed because they were deemed to be “harmful” and not teaching
people the right way to use cucumber. Aslak Hellesøy (the original
creator of cucumber) has written a great
post
on why using steps isn’t a great long-term strategy, along with some
suggested improvements (including abstracting out the business logic,
having conversations around the requirements, moving the steps to ruby
where it can be refactored).