2

I am new to Quality Assurance and Selenium.

I had been looking for the best tool that can be used for automating our website (built in .Net in MVC framework).

Let me tell you the architecture of the software:

Presentation Layer (MVC application)

  • Controllers
  • Views
  • Models

Business Logic Layer

BLL has been implemented using Facade pattern, its the core of our web application.

Data Access Layer

Okey, so my question are following:

1) What design pattern should I follow to test my 2 things: UI Testing and Business Logic Layer

2) As I have seen that selenium just drives the code that is written by me, since I have to code myself, what is the benefit of selenium for me if I myself has to write all the code in C#?

3) In case of NUnit, I have same question, How can NUnit benefitting me? As I again have to write the complete test code for testing my application. Like I have to place try catch for checking code etc. which area is benefited by NUnit for me?

I know C# and I will create application that will test my web app, what is the benefit for me since everything will be written by me?

  • So are you saying your testing your own code? – mutt Apr 27 '17 at 11:31
  • Yes, I am basically a developer in my company and have to automate my web application including testing of UI and Business logic layer. – Umar Apr 27 '17 at 11:32
  • Well, that violates test best practice, but if you have to can you clarify Unit tests and continuous integration...that part should cover everything except the UI. Are you doing unit tests? That is most commonly the developer part. – mutt Apr 27 '17 at 11:39
  • unfortunately we don't have any QA resource, I have read hundreds of blogs uptil now, but could not find exact solution. – Umar Apr 27 '17 at 11:52
  • and yes I need unit testing, can you please tell me how NUnit is beneficial for me? – Umar Apr 27 '17 at 11:54
1

I disagree with @mutt. Developers know the code and are best positioned to write both unit and system/UI/integration tests. Best practice is review the code by someone else (another developer): production code, unit and integration tests.

It is manual/investigative testing which should be done with someone else (not a developer), to gain a fresh perspective how a feature should behave.

Don't even start with UI/integration tests before you have a comprehensive set of unit tests. Unit tests are your first line of defense: if they fail, they point pretty closely to the cause of the breakage. All other tests are more separated from the tested code, so inevitable any detected error requires larger investigation (and should start with adding a unit tests for the cause).

After unit test, developers should write UI tests of basic functionality ("happy path"). If you have those, you can go two ways:

  • If you have automated test developers in QA, they can take over and write more complicated UI/integration test (more "adversarial", straying from "happy path", checking more error conditions).
  • If you don't have coders in QA, testers ("another set of eyes") can develop scenarios for automated tests beyond "happy path" and developers can code those

Either way, core developers should develop "happy path" UI test, because doing so they will add valid locators to widgets test need to interact with. If you dump "happy path" automated test on QA developers, many widgets will not have good locators, and QA will have to deal with bad clunky locators, or worse, XPath. Adding good locators is trivial for core developers, writing "happy path" test is the incentive for them to do so.

For UI test, strongly consider PageObject design pattern. Google for links.

  • We completely agree on the unit testing parts, so either way start there...I totally disagree that developers can write good functional tests though. I have yet after working with 250+ individual developers in many locations to find a developer who can write a test for their own work that is fully adequate. Extremely simple things sure, but the developer spends too much time writing what "should" happen that when it comes to testing they are unable to step back and look at it fresh like a user instead of just coding for success. Automation should not be just success paths based on code. – mutt Apr 28 '17 at 14:31
  • Caveat, I'm talking about functional ui tests, integration tests I have seen both ways successful, although I have always found a QA review of the integration tests helpful. – mutt Apr 28 '17 at 14:43
  • 1
    OP say they have no QA automation developers, so only coders available to develop UI/integration tests are core developers. – Peter M. - stands for Monica Apr 28 '17 at 14:44
  • 1
    I added edit, describing what is (in my experience) best mix of using developers to write "happy path" basic UI test (so they are forced to add good locators). QA developers can take it from there and write more "adversarial" tests. – Peter M. - stands for Monica Apr 28 '17 at 14:56
  • 1
    Re "adversarial": test are adversarial (stranding from "happy path"). Relations between devs and QA is not adversarial - it is cooperation, working together to create reliable regression tests without XPath locators. – Peter M. - stands for Monica Apr 28 '17 at 16:24
0

Best Practice: Testing should not be done by the same person who wrote the code with the exception of test driven development with unit tests and this still reviewed by other developers and sometimes the test part done by other developers to in order to have fresh eyes on the work.

That being said, you already have your directions to do all the tests yourself, so we will ignore best practice right now.

  • NUnit is a unit test framework (.Net) that provides assertions and results to executing code function/methods based on calls and inputs. It returns pass/fail results and is designed to test each coded piece of functionality for accuracy and error paths. General Unit testing info
  • For web applications the browser plays a part as a third party tool required for the code to work. Therefore in order to test UI code you have to be able to drive the browser itself in order to execute the code on the screen. Selenium WebDriver is able to read and access elements in the DOM on a browser. It also works with multiple browsers and also with mobile platforms via the wireframe protocol.

If you have to automate both back end and front end you need to utilize these in order to accomplish it. You can swap unit test frameworks and/or automation tool selections, but these are pretty standard selections for .Net webapps.

  • Yes it's writing more code to test the code, but that is the job with test automation. The focus is executing all aspects of the product code. – mutt Apr 27 '17 at 12:12
  • I highly appreciate you, but the main thing was to decide the design of project to be working for testing. In case of considering code testing through NUnit, I have certain classes which act like repositories, just simple C# classes that input/output data. Should I create one test class against one actual C# class (that is going to be tested). And should I create one function to test one function of that class? Basically this is the main probelm I can't decide uptil now. Forget that I am a developer or a Tester! :) – Umar Apr 28 '17 at 11:33
  • As you are automating from a development perspective it is likely that you will want to line up your code with automation to keep it organized, so 1 to 1 is not a bad way to go. See PageObject Design Pattern as @PeterMasiar mentions in his post to line up each page to automate which will likely line up with the code structure you mention. For MVC it follows along with the setup as you have each view with an automated test. I can't throw out the dev/test part as it's a different way of thinking, thus varying approaches. maybe helpful: infoq.com/articles/gui-automation-patterns – mutt Apr 28 '17 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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