3 ms·

Writing good automated tests doesn't necessarily rely on a great developer, it all depends on how you approach testing. For example, let's say you want to use S

Writing good automated tests doesn't necessarily rely on a great developer, it all depends on how you approach testing. For example, let's say you want to use Selenium to write web UI tests. One common approach is to have developers create a page object model, which testers can then use to write readable and robust tests. Creating a page object model is a simple task, and working with that page object model is a simple task, as the model guidelines define an easy to implement and easy to follow control structure (essentially all page object methods must return another page object, which means you can chain them together). Oh and MS Paint would be easy to create a good test suite for. For what it's worth I'm a software tester by trade, so perhaps it's straightforward for someone who creates tests for a living to know how to approach it, I guess someone who was inexperienced wouldn't necessarily know how to approach it.

lovich 10y ago
Do you have any suggestions on where to learn more about testing? I've gone through numerous tutorials and read through The Art of Unit Testing but I still feel like I'm writing tests just to write tests. It's not really clicking for me
- ZenoArrow 10y ago
  Sure. First of all, even though you're clearly a developer (as you mentioned writing unit tests), I'd recommend starting at a higher level of abstraction with BDD tools, basically anything that implements the Gherkin language (I can't tell you which BDD tool to use as I don't know what language you're coding in, if you can tell me I can give you a more specific recommendation). The idea behind this is that you're writing your code to meet a specification that your client can also work with, so you can be sure the specification you're coding against is what the client wants. As an added bonus, the Gherkin scripts form a type of living documentation, providing clear information about what the application does whilst also remaining up to date (so long as all tests must pass before a new version is sent out). Second recommendation is to look into how to avoid test-induced damage, which is where code gets bloated and more complicated in order to make it more testable. One major source of problems in this area is the need to create mock objects. I'd recommend this video from Mark Seemann as a good starting point in this area, as it looks at how you can create unit tests without mocks: https://www.infoq.com/presentations/mock-fsharp-tdd https://www.infoq.com/presentations/mock-fsharp-tdd If you can let me know which language you're mostly coding in I'll see if I can give you some more recommendations.
  - lovich 10y ago
    I'm doing 90%+ of my code in C#/vanilla JS at the moment. I was using moq to mock out my C# objects. Thanks for the help, by the way
    - ZenoArrow 10y ago
      You're welcome. As you're familiar with C#, I'd recommend SpecFlow. http://www.specflow.org/ http://www.specflow.org/ As you're also using JS I'm guessing you're creating web apps, so I can recommend Selenium if you want to automate front end tests. You can code Selenium tests with C# too, and you can also abstract away the details of the Selenium implementation to use SpecFlow to write the tests. If you have access to Pluralsight (if you have an MSDN licence check to see if it's bundled with your MSDN licence, I think I got a 45 course Pluralsight trial with my MSDN Enterprise licence), there's some good courses on Selenium and SpecFlow, including one that takes you through combining the two. http://www.seleniumhq.org/ http://www.seleniumhq.org/ https://www.pluralsight.com/ https://www.pluralsight.com/
      - lovich 10y ago
        You've got it right on the web apps. And thanks again, this should be a big help
AstralStorm 10y ago
You think it would be easy, but UI tests automated by things like Selenium are hard coded sequences. As far as I remember, they do not run randomised collections of features with randomised data input. Plus they do not verify application state really, just that it does not crash. What if it just looks and acts funny?
- ZenoArrow 10y ago
  I've used Selenium. Perhaps you missed that I said I'm a software tester. This sort of stuff is my bread and butter. In terms of values, there are well established guidelines you follow when picking those values, for example boundary cases. As for "looks and acts funny", that's why you still have exploratory testing. Automated testing can drastically cut down on overall testing time, but there's still the need to perform exploratory testing to look for quirky issues.

lovich 10y ago

Do you have any suggestions on where to learn more about testing? I've gone through numerous tutorials and read through The Art of Unit Testing but I still feel like I'm writing tests just to write tests. It's not really clicking for me

ZenoArrow 10y ago
Sure. First of all, even though you're clearly a developer (as you mentioned writing unit tests), I'd recommend starting at a higher level of abstraction with BDD tools, basically anything that implements the Gherkin language (I can't tell you which BDD tool to use as I don't know what language you're coding in, if you can tell me I can give you a more specific recommendation). The idea behind this is that you're writing your code to meet a specification that your client can also work with, so you can be sure the specification you're coding against is what the client wants. As an added bonus, the Gherkin scripts form a type of living documentation, providing clear information about what the application does whilst also remaining up to date (so long as all tests must pass before a new version is sent out). Second recommendation is to look into how to avoid test-induced damage, which is where code gets bloated and more complicated in order to make it more testable. One major source of problems in this area is the need to create mock objects. I'd recommend this video from Mark Seemann as a good starting point in this area, as it looks at how you can create unit tests without mocks: https://www.infoq.com/presentations/mock-fsharp-tdd https://www.infoq.com/presentations/mock-fsharp-tdd If you can let me know which language you're mostly coding in I'll see if I can give you some more recommendations.
- lovich 10y ago
  I'm doing 90%+ of my code in C#/vanilla JS at the moment. I was using moq to mock out my C# objects. Thanks for the help, by the way
  - ZenoArrow 10y ago
    You're welcome. As you're familiar with C#, I'd recommend SpecFlow. http://www.specflow.org/ http://www.specflow.org/ As you're also using JS I'm guessing you're creating web apps, so I can recommend Selenium if you want to automate front end tests. You can code Selenium tests with C# too, and you can also abstract away the details of the Selenium implementation to use SpecFlow to write the tests. If you have access to Pluralsight (if you have an MSDN licence check to see if it's bundled with your MSDN licence, I think I got a 45 course Pluralsight trial with my MSDN Enterprise licence), there's some good courses on Selenium and SpecFlow, including one that takes you through combining the two. http://www.seleniumhq.org/ http://www.seleniumhq.org/ https://www.pluralsight.com/ https://www.pluralsight.com/
    - lovich 10y ago
      You've got it right on the web apps. And thanks again, this should be a big help

AstralStorm 10y ago

You think it would be easy, but UI tests automated by things like Selenium are hard coded sequences. As far as I remember, they do not run randomised collections of features with randomised data input. Plus they do not verify application state really, just that it does not crash. What if it just looks and acts funny?

ZenoArrow 10y ago
I've used Selenium. Perhaps you missed that I said I'm a software tester. This sort of stuff is my bread and butter. In terms of values, there are well established guidelines you follow when picking those values, for example boundary cases. As for "looks and acts funny", that's why you still have exploratory testing. Automated testing can drastically cut down on overall testing time, but there's still the need to perform exploratory testing to look for quirky issues.