Why Thread.Sleep is bad Practice

1. The thread time slice varies from OS to OS and processor to processor. This means that once your thread goes to sleep, it’s going to wait for its turn to come back into the scheduler. So it’s highly likely that the thread.sleep time means more than what you really intended. For example, with thread.sleep(1000), you intended 1,000 milliseconds, but it could potentially sleep for more than 1,000 milliseconds too as it waits for its turn in the scheduler.

1. Each thread has its own use of CPU and virtual memory. That means our thread acquired its resources (say 1MB virtual memory, some CPU cycles and some context switching cycles), and is simply not using them.

1. If it’s a foreground thread, it’s preventing the application from exiting as well.

1. What about Thread.Sleep(0)? This tells the processor that I’m ready to lose the remainder of my time slice, and you may pick up the next thread from the queue. On one hand, it feels good and efficient. But on the other hand, you are also telling the processor that you are better at scheduling than the processor. (I don’t know the side effects this can cause, but I’m not smarter than the processor.)

We are talking about milliseconds when dealing with thread.sleep, but it’s important to understand that the more we use thread.sleep, the more we defer solving the real problem, which is how to handle async in modern web apps.

Comparing XUnit, NUnit and Visual Studio

When you find yourself (or your company) with more code than anyone could ever test by hand, what can you do? Well, unit testing has always been the perfect solution, as you can run tests that check more data than a person could in a day in a matter of milliseconds. So today I’ll take a look into a few popular C# unit testing frameworks and try them out first hand so you can choose which one best suits your project.
Unit tests can be run as often as you want, on as many different kinds of data as you want and with next to no human involvement beyond once the tests are written.
Not only that, but using code to test code will often result in you noticing flaws with your program that would have been very difficult to spot from a programmer’s viewpoint.

Raygun lets you detect and diagnose errors and performance issues in your codebase with ease

It takes minutes to add Raygun into your software. Be alerted to issues affecting end users and replicate problems 1,000x faster than using logs and incomplete information from users. Learn more and try Raygun free for 14 days.

Popular C# unit testing frameworks

The unit testing frameworks I’ll be testing are:

• NUnit
• XUnit
• Built-in Visual Studio testing tools

All of these unit testing frameworks offer a similar end goal, to help make writing unit tests faster, simpler and easier! But there are still a few key differences between them. Some are more focused towards powerful complex tests, while others rank simplicity and usability as a higher priority.

First up is Microsoft’s own built in Visual Studio unit testing tools

In most versions since 2005, Visual Studio has come with a built in testing framework supported by Microsoft. This framework certainly wins the most points for installation. Though if your copy of Visual Studio doesn’t come with it already included you are going to have to jump though a few hoops to get it going. (We wrote a review of the 2017 version of Visual Studio here.)
This framework is the simplest of the three, and uses an easy to understand method attribute structure (much like most testing frameworks) where you are able to add tags such as ‘[TestClass]’ and ‘[TestMethod]’ to your code in order to get testing.
Visual Studio even has a UI panel dedicated to visualizing your tests, which can be found under Test -> Windows -> Test Explorer.

Now before we dive into trying out this testing framework let’s introduce our example classes that need testing.
First we have a Raygun, which we can fire and recharge. The only thing we need to keep track of with our Raygun is it’s ammo, which can run out.
We also have a bug, which we can shoot at with our Raygun. But this bug has the ability to dodge our attempts to shoot it.
If we shoot at a bug after it has just dodged, we will miss. Though if we hit the bug square on, it’s safe to assume that it will be dead.
These two classes are defined as follows:

public class Raygun {

 private int ammo = 3;

 public void FireAt(Bug bug) {
  if (HasAmmo()) {
   if (bug.IsDodging()) {
    bug.Miss();
   }
   else {
    bug.Hit();
   }
   ammo--;
  }
 }

 public void Recharge() {
  ammo = 3;
 }

 public bool HasAmmo() {
  return ammo > 0;
 }
}

public class Bug {

 private bool dodging;
 private bool dead;

 public void Dodge() {
  dodging = true;
 }

 public void Hit() {
  dead = true;
 }

 public void Miss() {
  dodging = false;
 }

 public bool IsDodging() {
  return dodging;
 }

 public bool IsDead() {
  return dead;
 }
}

Seems simple enough, but we need to make sure that our Rayguns and bugs behave as we want them to.
So then it’s time to write some unit tests! (We wrote about how to write robust unit tests in C# here.)
First up let’s try a simple situation where we want to shoot at, and hit, a bug.
What we would expect is that afterwards the bug will be dead, and the Raygun will still have a bit of juice left in it.
Well, let’s see if we are right:

[TestClass]
public class Class1
{
 [TestMethod]
 public void TryShootBug() {

  Bug bug = new Bug();
  Raygun gun = new Raygun();

  gun.FireAt(bug);

  Assert.IsTrue(bug.IsDead());
  Assert.IsTrue(gun.HasAmmo());
 }
}

The two new things you will notice in this snippet of code is the [TestClass] and [TestMethod] tags, which certainly don’t just float around in normal code.
These tags are what allow Visual Studio’s built in testing framework to recognize this particular class as a class that contains unit tests, and to treat the method TryShootBug() as a test case, instead of just an ordinary method.
Since these tools are built for Visual Studio, running your tests from within Visual Studio is very simple.
Just right click on any [TestMethod] tags as shown:

And would you look at that, the test passed. Looks like our Raygun can at least hit a stationary bug.
Of course this is only showing the bare basics of what Visual Studio’s testing tools can do.
Some other very useful tags you will surely be using are the [TestInitialize] and [TestCleanup] tags.
These tags allow you to specify code that is run before (initialize) and after (cleanup) every individual test is run.
So if you want to reload your Raygun after every encounter like a stylish gunslinger, then this should do the trick:

[TestInitialize]
public void Initialize() {
 gun = new Raygun();
}

[TestCleanup]
public void Cleanup() {
 gun.Recharge();
}

Stylish.
While we are still talking about the Visual Studio testing tools I’ll quickly mention the [ExpectedException] tag, which is incredibly useful for when you want to deliberately cause an exception in your test (which you will certainly want to do at some point to make sure your program isn’t accepting data it shouldn’t).
Here’s a quick example of how you would write a test that results in an exception:

[TestMethod]
[ExpectedException(typeof(System.IndexOutOfRangeException))]
public void TryMakingHeapsOfGuns() {

 Raygun[] guns = new Raygun[5];
 Bug bug = new Bug();

 guns[5].FireAt(bug);

}

Don’t worry about the index out of bounds exception, thanks to the [ExpectedException] tag the exception will be treated as a success and your test will pass. On the contrary if the exception isn’t thrown then the test will fail. Anyway, it’s about time we moved on to some more testing platforms!
Overall the built in Visual Studio testing tools do exactly what they say on the box. They are simple, easy to use and handle all the basic testing functionality you would need. Plus if you’re already working in Visual Studio then they are already ready to use!

Next up is arguably the most popular C# testing platform, NUnit

NUnit is an incredibly widely used tool for testing, and it serves as an excellent example of the open source unit testing frameworks. It’s a broad and powerful testing solution. In fact it’s what we use here at Raygun for the bulk of our unit testing.
NUnit is installed via a NuGet package, which you can search for within Visual Studio.
The packages I’ve used for this example are NUnit and NUnit.ConsoleRunner, though you also have the option of installing a GUI-based plugin for Visual Studio.
NUnit uses a very similar attribute style system just like the visual studio testing tools, but now we will be referring to a [TestClass] as a [TestFixture], and a [TestMethod] as simply a [Test].
Now let’s go back to our Rayguns and bugs and have a look at another example, but this time using NUnit.
This time let’s make sure our dodges and ammo are working properly, so let’s try and shoot a much more mobile bug:

[TestFixture]
public class NUnitTests {

 [Test]
 public void TryShootDodgingBug() {

  Bug bug = new Bug();
  Raygun gun = new Raygun();

  bug.Dodge();
  gun.FireAt(bug);

  bug.Dodge();
  gun.FireAt(bug);

  bug.Dodge();
  gun.FireAt(bug);

  Assert.IsFalse(bug.IsDead());
  Assert.IsFalse(gun.HasAmmo());
 }
}

Notice the new [TestFixture] and [Test] tags.
Now in order to run this test using NUnit, we need to seek the command line (unless of course you’ve chosen to install a GUI based plugin.)
First, you must make sure you are in your project’s root directory (e.g. C:\Users

yourUserName\Documents\Visual Studio 2015\ProjectsYourProjectName) and then enter the following command in a new cmd window:packages\NUnit.ConsoleRunner.3.6.0\tools\nunit3-console.exe  YourProjectName\bin\Debug
YourProjectName.dllAssuming everything is set up properly, the NUnit console runner will run all the tests in your project and give you a nice little report on how things went:

Looks like our bug sure can dodge and our Raygun can certainly run out of ammo!
One feature of NUnit that makes it incredibly useful is the ability to include parameters in your tests!
This means that you can write a test case with arguments, then easily run the same test with a range of unique data. This removes the need to write unique test cases for every set of arguments you want to test.
Here’s a quick example test case we could use to make sure our Raygun was actually running out of ammo at the right time, in a much smarter way than before:

[TestCase(1)]
[TestCase(2)]
[TestCase(3)]
[TestCase(4)]
public void FireMultipleTimes(int fireCount) {

 Bug bug = new Bug();
 Raygun gun = new Raygun();

 for(int i = 0; i < fireCount; i++) {
  gun.FireAt(bug);
 }

 if (fireCount >= 3) {
  Assert.IsFalse(gun.HasAmmo());
 }
 else {
  Assert.IsTrue(gun.HasAmmo());
 }
}

Excellent, with this one test case we were able to make sure a Raygun which has fired two shots still has ammo, while one that has fired three is empty. And thanks to the [TestCase] tag we were easily able to test a whole bunch of other values while we were at it!
Overall NUnit is an excellent testing framework, and as you delve deeper into what it can offer, it surely exceeds what Microsoft’s built in testing can offer.
Anyway, let’s look at our last testing framework, and our last attempt as shooting bugs with Rayguns!

If you like the sound of Facts and Theories, then it’s time to look at XUnit

XUnit is an open source testing platform with a larger focus in extensibility and flexibility. XUnit follows a more community minded development structure and focuses on being easy to expand upon.
XUnit actually refers to a grouping of frameworks, but we will be focusing on the C# version.
Other versions include JUnit, a very well known testing framework for Java.
XUnit also uses a more modern and unique style of testing, by doing away with the standard [test] [testfixture] terminology and using new fancy tags like Facts and Theories.
NUnit and XUnit are actually quite similar in many ways, as NUnit serves as a base for a lot of the new features XUnit brings forward.
Note that XUnit is also installed via a NuGet package much like NUnit, which you can search for within Visual Studio. The packages I’ve used for this example are XUnit and XUnit.ConsoleRunner, though you also have the option of installing a GUI-based plugin for Visual Studio.
Much like the [TestCase] tag in NUnit, XUnit has its own solution to providing parameters to a test case. To do so we will be using the new [InLineData] tag and Theories.
In general, a test case that has no parameters (so it doesn’t rely on any changing data) is referred to as a Fact in XUnit, meaning that it will always execute the same (so ‘Fact’ suits it pretty well). On the other hand, we have Theories, which refers to a test case that can take data directly from [InLineData] tags or even from an Excel spreadsheet
So with all these new fancy keywords in mind, let’s write a test in XUnit that uses a theory to test our bugs dodge ability:

[Theory]
[InlineData(true, false)]
[InlineData(false, true)]
public void TestBugDodges(bool didDodge, bool shouldBeDead) {

 Bug bug = new Bug();
 Raygun gun = new Raygun();

 if (didDodge) {
  bug.Dodge();
 }

 gun.FireAt(bug);

 if (shouldBeDead) {
  Assert.True(bug.IsDead());
 }
 else {
  Assert.False(bug.IsDead());
 }
}

This test covers both cases at once, where the bug dodges and survives, or doesn’t dodge and gets hit. Lovely!
Now, last step, lets run the XUnit test runner from the command line (note that much like NUnit, XUnit also has a GUI based visual studio plugin available for you to run tests with).
First you must make sure you are in your project’s root directory, just like NUnit (e.g. C:\Users
yourUserName\Documents\Visual Studio 2015\ProjectsYourProjectName) and then enter the following command in a new cmd window:packages\xunit.runner.console.2.1.0\tools\xunit.console.exe  YourProjectName\bin\Debug
YourProjectName.dllAssuming everything is set up properly, the XUnit console runner will run all the tests in your project and let you know how your tests turned out.

Looks like our dodging tests passed!
Overall XUnit acts as the more contemporary version of NUnit, offering flexible and usable testing with a fresh coat of paint.

In conclusion…

Regardless of which of the unit testing frameworks you use, you’re going to be getting all the basics. However, there are a few differences between them that I hope I’ve highlighted so you can choose the right one for your project. Whether it’s the convenience of Microsoft’s built in unit testing framework, the solid and well proven status of NUnit, or the modern take on unit testing that XUnit provides, theres always something out there that will give you exactly what you need!

Want to add an extra layer of protection for your code? Catch the errors that fall through the cracks with 

SDET Roles

• 

• Home

• Testing

• SAP

• Web

• Must Learn!

• Big Data

• Live Projects

• AI

• Blog

What is SDET? Full Form, Meaning, Role and Responsibilities

What is an SDET?

SDET is an IT professional who can work equally effectively in development and testing. Full form of SDET is Software Development Engineer in Test and he/she takes part in the complete software development process.

An SDET's professional's knowledge is entirely focused on testability, robustness, and performance. They are also able to play a contributory or reviewer role in the creation of designs for production software.

In this tutorial, we will learn-

• Difference between SDET and tester?
• When do you need SDET?
• Industries in need of SDET
• Technical and Nontechnical skills needed for an SDET job
• What are the roles and responsibilities of an SDET?
• Salary
• Typical work Day
• Career Progression
• Conclusion

Difference between SDET and Tester?

SDET	Manual Tester
Knows the entire system start to end	Limited knowledge about the system
SDET is involved in every step of the software development process like Designing, development, and testing.	QA is only involved in the testing life cycle of the software development process.
Highly skilled professional with development as well as testing knowledge.	Software tester is only involved in preparing and executing the test cases
SDET can participate in test automation tool development and may make it for generic use.	Not expected to develop test automation tools or frameworks.
SDETs need to perform duties like performance testing, automated generation of test data, etc.	Only testing related task will be performed by the tester.
Know requirements and guidelines for the products	No such knowledge expected from QA professionals.

When do you need SDET?

Today organizations are looking for a professional who can take part in software development. At the same time, he should also handle testing of the developed software. That's why hiring SDET helps them as they can work for developing high-performance code or designing the testing framework.

Benefits of SDET professional:

• SDETs professionals can automate the acceptance test by leveraging their coding skills
• These professionals deal with end users or customers and their experiences. They already possessed engineering skills so they can also think like a developer.
• Extensive code coverage through unit testing
• Can build, deploy, run & manage the application individually
• Influence the development, program management, & design teams on technical implementation and user scenarios

What is Difference Between SDET and TESTER?

On a high level side, SDET can be seen as a software developer and also a tester but he will be a part of testing phase and not of development phase of the software development life cycle. To better understand the differences between SDET and Tester, read below points.

• SDET is highly skilled resource with development as well as testing skills; on the other hand tester is involved in preparing and executing the test cases either manually or by automation.
• Testers are resources with limited programming skills and they are much focused on black box or functional testing whereas SDETs are skilled resources with good programming skills and do the job of tester (white box testing) as well as developer in test automation.
• SDET being very proficient in software development, they can participate in test automation tool development and may make it for generic use. Testers are not expected to develop test automation tools, they may use these test automation tool to automate the test cases required for their software application or project.
  
• Often it is seen in an organization, tester or Quality Analyst who have developed the test automation framework are promoted to new role as SDET and can participate in review of design of software application or other test automation framework.
• In a comprehensive example we may demonstrate this, if the testing of an API is to be conducted then it cannot be done without writing any line of code. Therefore the test role here could be SDET. However if it is to test user interface or GUI which requires the black box testing and there is no need to write any line of code to test, this test role here could be STE (Software Test Engineer).
• SDET are expected for more duties over general testing role like performance testing, security testing, automated generation of test data, test environment setup, developing test automation tool etc.
• Unlike manual testers, SDET are expected to have domain knowledge so that they can participate in designing the test cases. All duties of a tester are expected from SDET.
• Some organization like Microsoft do not differentiate between the various roles of the tester and expects them to run test manually as well as write test automation scripts or code if needed. Organizations now a days emphasis tester to learn at least one programming language which they can use to work on test automation tools. Also test automation tools like Selenium, FitNesse, SAHI, etc. have flexibility and are available to operate in various programming languages like Python, Pearl, JAVA, etc.

Roles and Responsibilities of SDET:

• SDET is an Engineer: They know many programming languages, database concepts, participates in product design, data design and user interfaces.

• Software Testers Who can code: SDETs should know to build and test product that can meet user expectations. To test any application deep enough, one should understand the code upon which that application or product is built. Testing starts right at unit level up to its function level with acceptance and product performance testing. A SDET is proficient in all of these testing. SDETs can automate the acceptance test by leveraging their coding skill.

• SDET is Customer Advocate: SDETs voice are very important as they know everything on a product. They have participated in all level of product design, worked with product manager, product development team and end product user. They understand the need of a software product as a whole therefore they are the best customer advocate.

• Different role from QA or Software Tester: A Quality Analyst (QA) tests the software only after the development phase is over whereas SDETs are active during the development phase and work shoulder to shoulder with developer to understand the underlying code. QA role is not as technical as an engineer. Software tester on the other side is focused on all the steps of software development lifecycle, they prepare test cases and execute them to find bugs in a software product or application and ensures high quality software product release. This is also the part of Job duties for a SDET.

• Heart and Brain of the Process: Being part of the project management, SDETs deal with end users or customers and their experiences and they already possessed engineering skills. This all in one job exposure and skill set make SDETs the heart and the brain of the software process.

Conclusion: SDET are not just more than a tester. SDET is a mix of developer as well as tester who has exposure to project management, interacts and understands end user software requirements, knows product or domain knowledge, participates in product or software designing, knows how to code and build test automation tools. This all in one kind of skill set make the SDET role very unique and high demand in present software industry.

If you are not regular reader of this website then highly recommends you to sign up for our free email newsletter!! Sign up just providing your email address below:

Industries in need of SDET

There is a trend among companies to adopt new technology and methodologies. Therefore, SDET software professionals are highly on demand. Software developer engineer in the test are mainly needed in the following fields:

Technical and Nontechnical skills

Following are some essential nontechnical skills for an SDET:

Communication skill

A SDET must have excellent verbal and written communication skill. Testing materials like test cases, plans, test strategies, bug reports created should be easy to read and comprehend.

Time Management & Organization Skills

An SDET job is very demanding especially during the release of code. A software tester must efficiently manage workload, have high productivity, time management skills

GREAT Attitude

To become good Software Development Engineer in Test, you must have a GREAT attitude. You should able to upgrade your technical skills with the changing technologies. Your attitude should have some level of independence. So that, you can take ownership of the task allocated without too much supervision.

Passion

To enjoy success in any IT professional, you must have a significant degree of the passion for it. A SDET should have a passion for testing, development, and designing.

Below given are some Technical skills expected from SDET:

• Knowledge of C#,.NET, Java or other programming languages.
• Experience of working "AGILE + DevOps" process management methodology.
• SDET should have knowledge about various test method & corresponding tools like MS Test, NUnit, TestNG, Selenium WebDriver, etc.
• SDET should have exposure to Behaviour Driven Development.
• Able to find bottlenecks and thresholds in existing code with the help of automation tools.
• Understanding of Object-Oriented Design

What are the roles and responsibilities of an SDET?

• SDET should able to perform Test Automation and setting up frameworks on multiple application platforms like Web, Mobile, and Desktop.
• Investigate customer problems referred by the technical support team.
• Create & manage bug reports and communicate with the team.
• Able to build different test scenarios and acceptance tests.
• SDET needs to handle technical communications with Partners to understand client's systems or APIs.
• SDET also work with deployments teams and resolving any level issues for the system.
• SDET should also able to set up, maintain, and operate test automation frameworks.

The above are key skills and responsibilities of SDET. They may vary with different companies.

Salary

The salary structure of a SDET varies from company to company. The average annual salary for a Software Development Engineer in Test (SDET) is ₹6,92,692 in India and $74,291 in the USA.

An SDET is also given health insurance, gratuity, and other perks.

Typical Work Day

On a daily basis, you will be busy understanding project documents, creating & executing test cases, reporting, and testing bugs. You will also put your inputs to designing team, suggest development team and other team building activities.

Career Progression

Your career progression as a SDET in typical CMMI level 5 company will look like following but will vary from company to company

SDET (Fresher) => Sr. SDET (2-3 years' experience) => SDET Team Coordinator (5-8 years' experience> =>SDET Manager (8+ years' experience)

Conclusion

A SDET professional is a mix of developer as well as a tester who has exposure to project management. This all in one type of skill set make the SDET jobs more challenging and highly demanding in the current market.

How do i know when a page has finished loading in selenium c#

IJavaScriptExecutor js = (IJavaScriptExecutor)driver;
  WebDriverWait wait = new WebDriverWait(driver, new TimeSpan(0, 0, timeoutSec));
  wait.Until(wd => js.ExecuteScript("return document.readyState").ToString() == "complete");

How to find element is loaded or not in selenium c#

1. To check Element Present:

   if(driver.findElements(By.xpath("value")).size() != 0){
   System.out.println("Element is Present");
   }else{
   System.out.println("Element is Absent");
   }

   Or

   if(driver.findElement(By.xpath("value"))!= null){
   System.out.println("Element is Present");
   }else{
   System.out.println("Element is Absent");
   }

2. To check Visible:

   if( driver.findElement(By.cssSelector("a > font")).isDisplayed()){
   System.out.println("Element is Visible");
   }else{
   System.out.println("Element is InVisible");
   }

3. To check Enable:

   if( driver.findElement(By.cssSelector("a > font")).isEnabled()){
   System.out.println("Element is Enable");
   }else{
   System.out.println("Element is Disabled");
   }

4. To check text present

   if(driver.getPageSource().contains("Text to check")){
   System.out.println("Text is present");
   }else{
   System.out.println("Text is absent");
   }