To start with, what everyone else said.
I'd suggest that your first goal should be to learn how to split your test cases into reusable chunks so your login is a single test case which gets called by all the others.
The method I use (regardless of tool) is to define a test case as containing one or more test actions, each with one or more steps, so a test case of (for example) logging into a webstore and ordering an item breaks down to a set of actions like this:
- Run targeted browser
- Load entry URL
- Log in as user
- Select quantity x of item y
- Select payment method
- check confirmation page
- exit browser
Each action can be used in any test case, so you only need the log in steps existing in one place.
I'll also typically have the actions take parameters so that I can reuse the action with different data. So the log in action would take in an identifier pointing to the user needed for the test case, and break down to steps something like this:
- Retrieve user details for user login 'testuser1'
- Enter user name
- Enter user password
- Click logon button
- Verify successful action
(Of course, if you include success/failure information in your user details, you can call a "successful action" one that has the expected result whether it be a logged in user or an invalid password message).
I've found - by starting the way you did, and dealing with the ever-growing collection of identical or almost identical code - that modularizing your test cases this way helps to keep things clean and easily maintained.