Mocks and stubs are very similar but there are two very big differences, stub use state verification while mocks use behavior verification.

In order to use state verification on the stub, I need to make some extra methods on the stub to help with verification. As a result the stub implements MailService but adds extra test methods.

Mock objects always use behavior verification, a stub can go either way. Meszaros refers to stubs that use behavior verification as a Test Spy. The difference is in how exactly the double runs and verifies and I’ll leave that for you to explore on your own.

Mocks can be much more useful in certain situtations because they are not real objects in the testing.

http://martinfowler.com/articles/mocksArentStubs.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

A non descriptive test name will cause anyone unfamiliar with the tests to be forced to read through the whole test code to figure out what is actually being tested. An example of this coming from the article is this code along with the test name:

@Test public void isUserLockedOut_invalidLogin() {
  authenticator.authenticate(username, invalidPassword);
  assertFalse(authenticator.isUserLockedOut(username));

  authenticator.authenticate(username, invalidPassword);
  assertFalse(authenticator.isUserLockedOut(username));

  authenticator.authenticate(username, invalidPassword);
  assertTrue(authenticator.isUserLockedOut(username));
}

Looking at this test the test name “isUserLockedOut_invalidLogin” is not descriptive enough considering what the test does. This causes us to have to look through the code and figure out that it locks the user out after 3 failed login attempts. A more appropriate test name would be “isUserLockedOut_lockOutUserAfterThreeInvalidLoginAttempts”. This test name tells us exactly whats going on and having to read through the code is not needed. The scenario and the expected outcome should be in the test name. This will save many hours by just having to read the test name instead of reading through code to figure out what the test is doing.

https://testing.googleblog.com/2014/10/testing-on-toilet-writing-descriptive.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

I have made a post previously containing what End-to-End tests were and there advantages and disadvantages. In this post I will compare End-to-End testing to Unit testing. Unit testing is done by taking a small area of an application and isolate it and then perform tests. This produces fast reliable tests.

With end-to-end testing you must wait until the software is complete before any tests can be created. The test results tend to be unreliable, and if a bug is found it is not known where it was found. The advantages of unit testing outweigh the advantages of end-to-end testing.Unit testing is fast, reliable and can find failures easily. End-to-end testing is slow, not very reliable and failures are hard to find, the only benefit to end-to-end testing is that it can more effectively simulate a real user. But that alone does not outweigh unit testings advantages.

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Testing a method with multiple behaviors with just one test could be dangerous. Since most methods output multiple different behaviors, such as a method that sends an email that displays a notification of what they bought along with a warning of a low balance. If we were to test this method in one test we are not covering both behaviors thoroughly. So we should have two separate test, one that tests the notification and one that tests the low balance.

Testing behaviors ensures all other methods will not be affected by a bug in a behavior. Also whenever a behavior is added to a method, a new test can easily be added without disrupting previous tests.

https://testing.googleblog.com/2014/04/testing-on-toilet-test-behaviors-not.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

UI tests are tests that make sure the app returns the correct output based on user input in the UI. Tools are needed to automate these tests, such as Espresso. I will be going over four different techniques for doing these automated tests.

End-to-End: this way of testing makes sure the whole system is functioning correctly. But using this method can be very large and slow but it covers the whole system.

Hermetic UI Testing Using Fake Servers: this method you can avoid using external dependencies. You chose what the server is sending to your app, so you have more control. This way reduces test sizes and improves accuracy, but you’ll have to maintain a separate server.

Dependency Injection Design: this will eliminate the need for a fake server. This makes it possible to mock dependencies, improving the accuracy of your tests.

Building Apps into Smaller Libraries: if you plan on adding more feature you should consider building your app into small libraries. This lets you mock dependencies for each library. This means smaller tests and increased accuracy.

https://testing.googleblog.com/2015/03/android-ui-automated-testing.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

End-to-End testing tests your entire system from one end to the other. Doing it this way makes everything from one end to the other black box. Using this way of testing, it will catch bugs across you entire system. The downside to End-to-End testing is it can be slower, less reliable and harder to maintain. Using this kind of testing you’ll want to focus more on the overall system health rather than focusing on small details.

Doing testing this way is not right for every situation. It is expensive to maintain and can be slow. The advantages may out weight the disadvantages in certain situations.

https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

When a new feature needs to be tested on a program sometimes testers will use old test documentation of a similar feature to help create tests. This is not an ideal way to create tests. I was unaware people did this and I thought it was a good idea until I did some more research.

Old test documentation gets out dated very fast. Testing is improving and changing constantly so using an set of tests might not be the best way to create a test. Also the program and environment may have changed, if this is true the old tests will not be helpful. So I’ve found that in most situations tests should be created from scratch to avoid any issues and also use technology that’s up to date.

http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

What is the difference between testing and checking? Some people may say it is the same thing, but there are some large differences. For example a human cannot perform checking, only a tool or machine can do that.

I did not realize there was a difference between testing and checking but upon reading this blog post and doing some research I found that there is one main difference. Testing is something humans do, when we analyze a program and create tests based off what we have learned, this is testing. Checking is something that a tool does to check a program. Checking is done one way by using algorithms to run through a program and perform checks based on the algorithm. That is the most important difference between the two, they both cannot be the same.

http://www.satisfice.com/blog/archives/856

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

As a student I am not familiar with acceptance testing mostly because it involves a client. With acceptance testing, the program is given to the business or client and the client makes sure all of their specifications were met. This is done throughout the development process, not just once the program is complete.

This is a great way to test but there are some issues. One of the biggest ones is communication, because the program is handed off from the client to the tester to the developer, not specifically in that order, communication is often lost. All three often do not work together but just pass off code or specifications. Another issue is exposure of the program to the client. This can lead to the client thinking they know how to fix issues or how to develop code. There should be a clear line that the client should stick to their business and the developers do their jobs.

After learning about acceptance testing these are only a couple of the many issues out there, but I thought they were some of the most important.

http://www.softwaretestingmagazine.com/knowledge/problems-acceptance-testing-can-cause/

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Testing can sometimes never be fully completed, so software is released that may contain bugs. If every software was completely 100% tested it might never get released. The two easy ways to know testing is over is if the deadline is met or the budget is exhausted. The test coverage should be 95% passing, and the test coverage should be at least 95%. All major defects should be fixed so the 5% failing tests should be small defects.

Knowing when testing is over can be hard, but these few tips helped me learn when to stop.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.