Likelihood to Recommend 1. It's open source which supports range of languages, operating systems and languages. Well suited for Android and IOS mobile automation. Supports all kinds of apps, which makes it flexible and robust mobile testing tool 2. It is less appropriate where we need intercept network call to verify the API calls. Extensive coding experience is required to work Appium
Read full review It is best suited for implementing the automated test cases in a human readable form so it's easy for non-technical members of the team and stakeholders to understand the test cases, features and the functionalities of the application. Automation of Integration tests and End to End tests are good use case. It is less appropriate or situations where the focus is only on the writing and maintenance of unit tests.
Read full review Pros It uses WebDriver API so it makes it easy to use for former web test automation engineers. It can be managed via the command line via an extensive set of parameters. It handles implicit waits at the server side that is especially valuable in distributed infrastructure. Read full review Versatility to be used in combination with different kinds of automated testing like automated performance testing, API testing, UI testing etc. I use JavaScript, Selenium, C#, email testing libraries, database testing libraries in combination with BDD with SpecFlow. I am able to use all these with SpecFlow to make my automation framework to be able to automate any kind of automated testing. It provides different widely used runner options like NUnit, XUnit etc. Before I started to work on establishing proper test automation in my workplace, the previous automation framework (non-BDD based) as well as unit tests used NUnit runner. The transition to using BDD was smooth because we could use the same runner and there were no compatibility issues. The auto-complete feature is good. I use it with Visual Studio as well as Rider and I don't have to recall the entire Gherkin statements. I just type a few words and the entire Gherkin statement implemented in framework is auto-suggested by SpecFlow. It saves time and context switching. Read full review Cons Element browser sometimes is unreliable and has sporadic fails. Appium running is a bit slow, compared to tests written with Appium and with Espresso or XCTest. Read full review SpecFlow does not accepts optional input variables in the methods defined during Gherkin statement implementation. Cucumber supports optional input variables in the methods defined during Gherkin statement implementation. The tests identified while using SpecFlow with NUnit removes all white spaces in the scenario names. It makes the tests less readable. If the white spaces are not auto-removed, it would be much better for readability as well as their actual identification in the repository. Read full review Alternatives Considered If you're an Apple developer, you use Xcode. It's practically a forced necessity. For system testing though, it doesn't have to be. You can have your development team focus on unit and integration tests in their platform and another team automate acceptance tests with a language they are more familiar with.
Read full review SpecFlow is .Net based which supports C#. Behave is Python based. Cucumber is Java based.
Ghost Inspector is no-code based but provides very limited testing features. We wanted to implement BDD so we rued out using
Ghost Inspector . Most of the developers in my team are C# experts so it was decided for everyone's comfort to go for SpecFlow rather than Behave or Cucumber. It's import to have technical experts in the language of the automation framework because there are many situations where the solutions to the test automation needs are not straightforward and implementing those requires expertise in the related programming language.
Read full review Return on Investment Appium is open source, so it's free. That's budget friendly right there. The ability to write mobile automation tests has saved considerable time for our manual test team, but that is true with most automation tests. We use Sauce Labs with our other automation, but Appium works great with Sauce Labs, as well, if I needed to run on emulators and simulators. Read full review Everyone stays on the same page regarding the behavior of existing functionalities whether it be technical or non-technical individuals. So there is less need for multiple people to get involved which saves time and thus money. Reusing the same code through the implemented Gherkin statement saves test automation time and thus reduces cost. We combine SpecFlow with other opensource testing technologies to make our automation framework more versatile which further saves costs for us. Read full review ScreenShots