10

The people I work with are .NET programmers that aren't exactly on the BDD/TDD bandwagon yet. I'm the main web designer, but for the past few months I've also been assigned the tester role as well (yeah, we're a tiny company).

I want to start incorporating some automated tests and after some research I'm more drawn to Watir/Cucumber and other Ruby-based tools.

Now I only test the GUI along with certain permissions (e.g. if I log in as a user, make sure I can't see what admins see, etc.) so I don't foresee any conflicts in terms of what language I use. Also, Ruby just feels a little easier to learn than C#/.NET.

However I'm wondering if there's anything I'm missing and whether it would just be easier to learn the .NET-based testing tools?

Improve this question
3
  • Thanks so much for everyone's help! I now have a better understanding of what to do and I'll definitely be talking to the development team about this and work out the best solution for all of us. Much appreciated :)
    – kleniq
    Commented Aug 10, 2011 at 5:02
  • You know, I only ever hear "what can go wrong" in movies, right before something really bad happens...
    – corsiKa ♦
    Commented Aug 30, 2011 at 16:25
  • What can go wrong? You learn that you like automated testing, and because your productivity in a dynamically typed language is higher, you would want to switch job to a place where they develop in Ruby or Python, so you can learn new skills from on-site experts.
    – Peter M. - stands for Monica
    Commented Jul 18, 2014 at 17:37

8 Answers 8

Reset to default
5

I agree that the language in general wont matter but with this caveat: since the product is coded in .Net you might look at the latest test tools that Microsoft includes with the tester edition of VS. The primary advantage being that tests and test documents could be managed in TFS, over time taking advantage of that could be helpful. Tests and test documents that live only on one persons machine are very fragile things.

Improve this answer
11

If you are the sole tester, and might continue to be for a while, it probably doesn't matter much if you choose whatever tool you personally prefer.

But if there is an expectation that other programmers will contribute to test automation, you should take their needs and preferences into consideration as well.

Then again, when your company grows enough, you may hire some dedicated testers who will then make their own test automation choices anyway.

Improve this answer
4

I am a big proponent of removing as many abstraction layers between my automated tests and the product code as possible.

Ruby or other scripting languages may seem fine for now, but if your test automation expands beyond simulating manipulating GUI elements you may find that C# may have been a better choice, to begin with for several reasons:

  • Performance, C# is more performant than many scripting languages. May not seem important now, but as test library grows the time it takes to run a suite may matter.
  • Collaboration, the dev can review and run automated tests. Being able to "plug in" to dev unit test, or another test harness allows you to push tests upstream
  • Capability, writing your test automation in C# can use reflection to access parts of product code to improve your overall test effectiveness and reduce false positives.

You may also want to look at here.

One final thought...talk with your development team and get their input. Perhaps Ruby (or another language) is sufficient for the needs of the company. Also, think about the potential future growth of the company and how needs might change in the foreseeable future.

Improve this answer
1
  • You forgot most important: programmer's productivity. In a dynamically typed language will be in my experience about 5 times of productivity of statically typed language like C#. Ability to flexibly create data literals to pass as parameters is much better in scripting languages. Performance on the executed code is almost irrelevant - all test will presumably will call the same libraries anyway.
    – Peter M. - stands for Monica
    Commented Jul 18, 2014 at 17:33
2

My answer is the old favorite: it depends. If you're looking for blackbox regression, the language doesn't matter, although it does help to have other programmers who understand what you're doing with automated tests that they can either help write it or help debug it. If you're looking to build unit tests, you're better off working with the same language as the code.

Also, a lot depends on the purpose of your testing. If your GUI evolves rapidly, you might prefer to work on behind-the-scenes validation of data processing. If GUI is critical, is it faster to do a quick visual, or do you need extensive validation of which components display?

I'd recommend you don't get hung up on the language you use - start by working out what aspect of your application most needs automated testing, then what offers you the most effective tools to perform that testing. Language can be learned, whether it's a scripting language, a pseudo-English test definition language, or one of the classical programming languages (or anything else for that matter).

I hope that helps you find a good starting point.

Improve this answer
2

If it is a very small company and you aren't mandated to use a specific tool set, I would choose whatever you prefer and what is easier for you to learn and be interested in. They are asking you to test the software with the best tools available and that's up to you.

That being said, if you don't want to be expected to maintain the testing suite forever you might want to consider using tools that the development team is experienced in using. One would hope they would be skilled enough to switch between the two but as companies grow things get more specific as far as platforms. This is based on my experiences though.

Also, if you're primarily a Mac or Unix user (with your background as a web designer), I think you'll have an easier time with a tool that runs natively in a Unix-like OS than having to be rolled into the .Net experience.

Additionally, as things grow up you may want to consider how testing is viewed (e.g. do you need pretty charts and graphs to spoon-feed product status to upper management? If so, you may want to look at tool sets that support that kind of feature.

Improve this answer
2

I don’t think that learning C# for testing purposes is way harder than learning Ruby. C# has a lot of syntax sugar that enables you to write less code.

With C# you could use WatiN (supports IE and FireFox only) or Selenium for Ref.

It does not depend on what language/platform you choose, but if you will have problems with C#, you can ask a developer who sits near you. But when you have problems with Ruby then whom will you ask?

Try to write several tests in both languages. And choose the language you are more comfortable with.

Improve this answer
1
  • +1 Highlighting this so it won't get lost in other replies, "...if you will have a problems with C#, you can ask a developer who sits near you. But when you have problems with Ruby then whom will you ask? "
    – user179700
    Commented Sep 2, 2011 at 3:30
1

Using C# would lower the barrier to entry for the developers to start TDD/BDD.

Improve this answer
1

Keep using the same two languages (KISS):

  • C#
  • English*

Use http://specflow.org/ to have gerkin style text only tests. It's not fancy and there's very little to go wrong with it. Plays nicely with TeamCity etc as the tests are normal MSTest / NUnit test assembiles.

I like them as they stop me getting side tracked with the implementation of the test, and they lead you down the path of building up your own bespoke testing language. (what would my pefect testing language look like for this problem domain?)

Improve this answer
1
  • * SpecFlow comes in many other languages...
    – Squirrel
    Commented Aug 22, 2011 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.