Return to Answer

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity.

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, data-stores and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse, to explain why not:

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity. Keep it simple!

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, data-stores and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse, to explain why not:

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity.

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, data-stores and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse, to explain why not:

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity.

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, data-stores and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse, to explain why not:

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity.

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, databases and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse:

TL;DR: There is no need for a framework at all. Using frameworks does not speed me up, just adds more complexity.

Most of the "Frameworks" classes that I build are Domain specific. For example setup test users by code. Clean up environments before test-runs.

I dont like to call it a framework, that would make it bigger than it is. It is not a re-usable chain of tools/libraries. The test boilerplate I use are:

• A unit-testing tool
• Simple pageObjects like classes (for views, data-stores and API's)
• WebDriver

I do have a couple of helper classes that most of my test projects have:

• environmentUnderTest settings (enabling same tests to run against staging, acceptance and production)
• WebDriver setup
• wait Helper
• tempPath Helper
• logger

I like to let new projects organicly grow and start with the most simple thing I need. I think I can setup a basic "framework" in a couple of hours.

Software can be complex, and it’s easy for teams to feel overwhelmed. To calm things down, and help deal with overwhelming complexity, one of XPs mantras is to do the simplest thing that could possibly work.

http://www.agilenutshell.com/simplest_thing

I see colegues in other departments trying todo what you suggest, creating an over-engineered and often over-generalized testing framework all teams and everyone can use. Creating a common DSL. Working for months to make the perfect framework. I have never seen it work. It makes building tests much more complex and includes a lot of magic that makes test failure debuging hard. If you need to train people how to use it, stop and think :)

For design that could means starting with something ridiculously simple, and adding more complexity just-in-time, if the next test warrants it.

I just automate tests and let a framework come to life, if it happens at all. If it happens it was needed, if it doesnt it wasnt. I duplicate code like a madmen and refactor/restucture my tests daily when ever I see a good abstraction.

Owh and this XKCD ofcourse, to explain why not: