Once an automation test is created, how do I test it and make sure the test does what its supposed to do? I can easily test the scenarios where test passes, but how to go about the ones that fails due to issues in site? Issues such as - an element missing, click not working etc. All I could think was to mock the HTML to simulate the condition to test and run the test in that local html.
Does any one else have better idea?
I think you are asking whether you need meta-tests (automated or otherwise). Of course, how do you know that a meta-test is correct? Here is what most developers do: if something feels risky, they test it; otherwise they trust that their code is correct. If something that they trust turns out to have a bug, they try to re-calibrate their judgement. You should do the same thing.
Personally, I would not go through the trouble to mock the HTML. If you have a site you can modify, you might try introducing bugs to see if your tests find them. Of course, you want to introduce realistic bugs, and it may not be easy to decide which bugs are realistic.
Edit
We test in order to reduce risk, but testing to excess can be ineffectual and even destructive. If you choose to write automated tests, you are subject to the same decisions that developers are subject to. Most developers do not choose to test every line of code. This is a good thing. Every line of automated test requires additional development effort and additional ongoing maintenance and will not necessarily find more bugs.
There is no hard and fast rule for deciding when to test and when to not test. The decision rests on your own experience, your confidence as a developer, your familiarity with the subject matter, your confidence in the code that you depend on, the maturity of your product, and other factors. Rather than looking for a hard-and-fast rule to follow dogmatically, try something that feels right, pay honest attention to your results, and re-calibrate accordingly.
Here is a rule of thumb that you could try. If testing something requires a huge effort, question your assumptions. You may be trying to test it the wrong way, or the thing you are trying to test may be more complicated than it needs to be, or you might even decide that the risk of it being wrong does not justify the cost of testing it.
When I'm automating a test, I often make the test wrong in some small but meaningful way, then run it with the expectation that it will fail. For example:
I'll do one of these at a time. I'll make the test wrong, run it, and notice whether it still passes. If the test now fails, and it makes sense to interpret the failure as due to my change, I'll conclude that the original test got that detail right, and change it back.
If the test still passes, that means the detail I changed does not have the effect I wanted, so I'll need to do some debugging.
If the test fails, but the failure isn't clearly attributable to the way I broke the test, I'll need to do some debugging.
Once I've tested the test in those ways, and once the system passes the test, I treat the test as being reasonably reliable until I discover some reason to doubt it (e.g. the test reports a failure, which might indicate a problem either with the test or with the system; or the test reports success when I have reason to believe the system or its environment is broken).
You can also take the mutant build approach: insert bugs in when generating the build and see if your coverage find any of them. The higher the number the better your coverage is, at least theoretically speaking :).
