When To Use These 5 TOP Software Test Types

5 types of test and when to use them. Software Testing is at the very heart of great software development, but there are lots of different kinds of tests. So which software tests are central to the development process, which are optional and which should you avoid altogether?

In this episode, Dave Farley author of best selling books “Continuous Delivery”, “Modern Software Engineering” and “Continuous Delivery Pipelines” talks about 5 types of test and their role in software development. This software testing tutorial will also mention why Integration tests aren’t strategic and where to use BDD and where not.

-

❗ TEAM TRAINING:

-
⭐ PATREON:

-

CHANNEL SPONSORS:

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

🔗 LINKS:

-

#developer #softwaretesting

[rothbardfreedom]

An Engineering Room about testing with James Bach would be a blast. He is releasing a book on Rapid Software Testing this year.

[chakala]

Hi Trisha and Dave, when people are discussing testing I rarely hear about ISTQB which is a good body of knowledge regarding testing. I would be glad to hear your take on it 😀

[rasmichael]

Manual testing has its place, certainly if you are developing anything that will be subjected to humans in production. If you don't let humans test then the customer will do that for you.
With predictable outcome...

[veenone]

Really love your thorough explanation! This will be a very good material for providing proper understanding of test activities both to the team and management who don't grasp the understanding of test activities properly

[BrandonToone]

Great video! Using acceptance tests to drive unit tests has worked well for me for a long time now.

Could you expand more on how to effectively use approval tests, particularly in the context of avoiding the common mistake of adding tests after writing the code?

[samvarcoe]

This was a really good video, thanks Dave. You've talked about all of these things before but it was definitely worth going over them again, this was really well packaged and presented.

[kampanartsaardarewut]

feels like you read my mind. I have been using acceptance test without integration tests for years when developing web services api

[DavidParry-Hacker]

This rocked and loved how you hit on the 2 most important tests at the end with solid reasoning.

[riesigerriese]

Thank you, Dave. As usual very dry and straight to the point.
I admire your patience explaining the same things again and again and again and again, tirelessly.
I'm so fed up explaining to my team mates that unit tests are way better when written first. They say: yeah, I'll do it later.
And then they complain that my tickets take too long. Cause I've got to write all the missing tests first, before I can make my change. 😮

[oliverglier]

Thank you for this nice overview and explanation. I also like healthchecks which perform expensive consistency tests for stored data and program behavior. A great deal of problems can be discoved befor currupted data spreads throughout the system. Secondly, I am fond of defensive programming by assertions and contracts. Contracts and assertions add so much clarity to the code. They allow errors to be discovered after release, and they allow (some) integration tests to become more like end-to-end tests. They are a prestep to provable correctness, and they bring their own complexity challenges (sometimes an assertion simply cannot afford a proportional amount of time).

[travisabrahamson]

One way I use Integration Tests is to learn about external to the app dependencies. Such as an Rest API. Here I can add tests to assure that when my app calls that API I get an expected response from the API. It helps isolate and quickly troubleshoot when a response I'm expecting does not occur from that API.

[chat-]

From my experience
* unit testing offers the most cake value when later someone modifies code. I've never understood or mastered TDD because it feels that it works against agility and requires a lot of planning.
* A different/better way of understanding acceptance tests. Interesting remarks as well. Usually it's the customer who signs off but i like this one more.
* From my experience the only automated tests that matter are unit and smoke tests. Smoke tests cover a lot of other tests including performance. I also like stress tests to validate and measure the tolerances of the architecture.
* Most niche products can't do automation tests unfortunately.
* I've always valued the idea that qa is not done by devs. Certainly for manual testing. With automation it gets a bit blurry because now the tester thinks like a programmer and brings those biases in, while the qa represents the moon power user.

[aurinator]

Types of testing:
Unit Tests 2:12
Acceptance Tests 5:50
- How they can be considered as synonymous-ish with Integration Tests from the Testing Pyramid 12:58
Approval Tests 13:44
Manual Tests 15:37

[sirskaro]

Dave, this was an excellent video and very encouraging to me because it has very similar content to what I preach almost daily at my work. I've been labeled as the automated testing expert in my department - which I feel like is being labeled as an expert in breathing.

I really like your list and plan on updating my testing evangelist slide decks with your ideas. One thing I'd like point out that I often start with in my slides is that I feel there are many ways to define what a "type" of test is. E.g., black box v. white box are types by methodology while Marick's quadrants are types based on function and yours are based off purpose. Perhaps I'm off course about this but I'm interested to hear your thoughts about this idea.

I've been experimenting lately with in-memory test doubles as part of my acceptance tests. So far I've found that they give me lots more confidence even though it doesn't add much code coverage and doesn't really exercise more of my code than if I use stubs. I'd be interested to hear more of what you think about heavier use of test doubles.

[logiciananimal]

Pentester etc. here - I describe my work in application layer pentesting as "acceptance testing in reverse". I guess this is sort of like how antimatter is matter in a broad sense. Instead of looking to see that it does what it should I focus on whether or not an application (or API, etc.) does what it shouldn't. I thus agree largely with this taxonomy. I would like, however, to see if TDD reduces confirmation bias. Done right - without focus on implementation etc. I would hazard a guess that it does. I mention this because I have long wondered whether or not unit testing (however useful) might provoke confirmation bias.

[DaveKirby-]

One minor quibble - in your video you say that acceptance tests work best when they do not refer to any implementation details, but the acceptance tests you show as examples are written in java using junit. The language used is a pretty massive implementation detail. The advantage of using something like Gherkin is that it is language agnostic, so you can write acceptance tests before the programming language has even been chosen, reuse them if you need to convert to a different language, and have a common test language if are using multiple programming languages for front and back ends. Gherkin is also easier for non-programmers to understand.

[FlaviusAspra]

Unit test is best done at the boundary of the domain model, as to not tie the tests to implementation details of the model.

[chakala]

But Dave aren't integration tests useful for testing integration points such as gateway classes and repositories? I always think about Integration Tests as testing my ''understanding and usage'' of external dependencies.

[enzoscardamaglia]

Thank you very much.
This really helped me a lot.

I've a question though, as a non native speaker: why do you use the term "acceptance" and not the term "end to end"?

[AFPinerosG]

Hello Dave, there is a growing trend in "isolated testing" in which it is recognized that having to deploy a full environment for complex systems, such as microservices, isn't ideal because it is expensive, slow or becomes a bottle neck. This trend usually suggests avoiding these "fully setup" shared environments. How does acceptance tests match this idea? Do acceptance tests need a full-blown production-like environment to run?

For example, if I have 10 applications getting deployed to this shared environment in parallel, are all of them tested at the same time? Do I need to deploy a partial environment for each of these 10 applications so they can simulate their full system tests?

I think the environment setup has become a big challenge for testing in the current architectures. I'd love to hear your advice on how to properly run acceptance tests in microservice environments. There's willingness to start working on these tests, but these concerns become a deterrent when you have a system with 40 microservices.