- This is not only for test framework but also development code as well. Code changes are inevitable, linear dependencies help minimize the side effect of code changes. Loop dependencies cause development hell. Here is a good lecture about why loop dependencies lead slow down the project. Link
2. Make robust and simple backbone of test framework strategy.
- This is pretty obvious statement I guess. The thing that I want to point out is that we need to sit down and think about framework design before starting to write test code. How test runner will interact with application and how test runner will prepare test data need to be thought through and determined. As we draw the overall design of the framework, we can see the dependencies and think about possible design patterns or strategy we cam apply.
3. Use object for multiple test data values.
- This is more like a tip. If test data is being passed throughout the tests and it contains several values (id, name, data etc.), encapsulate test data by using an object. This will help add and remove test data details easily and overwriting toString() method help you log your test data
4. Find proper category of test cases as you go
- This is from my personal experience. This might be not a problem for others. Normally you will have test suites and test cases. And test suites contains list of related test cases. Test case is normally one class(java, cs , etc) And you name the class (i.e. LoginPageTests.java or something). As you implement the test cases and as you add more test cases, you will find more specific test cases under that test case class. Let say for LoginPageTest.java you find javascript related test cases and non-java script related cases(this is just an example). What I did was creating a new class called LoginPageJavascriptTest.java. Since LoginPageTest.java was in version control for a while and I did not want to rename them for some other reasons. So my LoginPageTest.java is non-javascript test cases. This is not very cohesive class name for its purpose. The proper name would be LoginPageNonJavascriptTest.java. What I'm trying to say here is that as soon as you realize that non-cohesive name, step back and think about what is proper category for your class. What would be the more appropriate category for test suites and test cases. DO NOT STUCK with your class name you created 4 weeks ago. Be flexible of naming.
5. Re-factor implementation logic not test case steps.
- This is pretty challenging part for myself as well. I can see the duplicate code and have strong urge to re-factor them. This is mainly for readability. Your code is owned by your company and other test engineers will see or work with your code. Normally one test case has steps like set up, test procedures, assertion and clean up. I guess set-up and tear down(clean up) can be refactored. But if you refactor test procedures and assertion part, it will be hard for others to follow your steps or even harder for finding flaws in your test procedures.
6. Use helper method instead of hard-coded value
