So we finally got our recorded test to work.
What I've also done here for the sake of exemplary purposes is I've duplicated these recorded
tests.
I literally just copied and pasted them to pretend like we actually have a suite of tests
and you can just pretend and imagined with me that we have a suite of 500 recorded tests.
Not that it's possible to maintain a suite of 500 recorded tests but let's pretend and
imagine 500 is a good amount of automated functional test to have.
And let's pretend that we have those tests.
And the reason that I want to pretend that we have those tests is because I want to drive
a point home in that with a recorded automated functional tests.
It is all pure duplication.
So if you take a look at the test here compared to the test here compare to this test everything
is duplicated and of course I copied everything but there is no other way around it.
When you record a test you redo all of your steps and you rerecord every single action.
Regardless there's no other way about it.
So that's the point.
Now keep that in mind because any single change that we have to make as a result of a change
in our application on their test is going to affect all of those tests that directly
communicate with that application.
So take a look at this test right here test one fix too.
What about this test can be affected by the application under test.
Something about the application of the test can change that will cause our tests to break.
Now if you're looking at this test and it looks OK to you as if you don't think that
there's anything wrong with SS that is completely OK and I actually expect that from you because
I've been at multiple job situations where people are still using a recording replay
to do automated functional testing.
Why wouldn't they.
It seems so attractive when they hear a proposition that you can record your test you can record
the steps and then have them running within a few minutes and have a bunch of tests recorded
within a few minutes.
That sounds fantastic.
I would love that proposition.
But the problem is that when something in the application under test changes everything
about the test can break for example are you Arel can change any of the locaters here can
change these class names.
They can change these ideas can change of course it's not as likely but it's possible
the locaters can change the world can change even worse the usernames and passwords can
change as well.
One of the worst situations to deal with is has data management which is another beast
of its own.
But imagine trying to navigate from differences to prod.
You have to maintain all those usernames and passwords and you can't do that in a recorded
test do you RL.
What are you going to do when you go from dev to test to prod.
Are you going to hard code those you are rails into your scripts.
I've actually seen that done.
I've actually been at a workplace where we had about 100 or so automated functional tests
recording even though only 30 of them were actually testing any kind of functionality
because the other 60 the other 67 percent were just duplication of the first you know
30 percent of the tests because they had scripts for dev test and prod.
The scripts were doing the exact same thing.
The only difference was that you R-AL.
So now imagine how many lines of code you have to maintain the to be able to just look
after 30 tests.
That's insane.
And so any time any kind of application change happens it will break all of those tests.
And as opposed to fixing it in a single place.
Now you have to go to three different places for three different scripts to fix your tests.
And that's the entire point here.
The problem with recording replay is that a single change in your application can drastically
affect all of your tests in your application.
As long as they're touching it because all of your tests are directly touching the application
they will all be directly affected by a change in that application.
And so that's why everybody says automated functional tests are brittle because of course
they're brittle when you have a single change that needs to be updated in 500 different
instances.
Of course you're going to say that it's brittle and of course you're going to throw up your
hands in the air and complain.