Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Software Architecture with C# 9 and .NET 5

You're reading from   Software Architecture with C# 9 and .NET 5 Architecting software solutions using microservices, DevOps, and design patterns for Azure

Arrow left icon
Product type Paperback
Published in Dec 2020
Publisher Packt
ISBN-13 9781800566040
Length 700 pages
Edition 2nd Edition
Languages
Tools
Arrow right icon
Authors (2):
Arrow left icon
Gabriel Baptista Gabriel Baptista
Author Profile Icon Gabriel Baptista
Gabriel Baptista
Francesco Abbruzzese Francesco Abbruzzese
Author Profile Icon Francesco Abbruzzese
Francesco Abbruzzese
Arrow right icon
View More author details
Toc

Table of Contents (26) Chapters Close

Preface 1. Understanding the Importance of Software Architecture 2. Non-Functional Requirements FREE CHAPTER 3. Documenting Requirements with Azure DevOps 4. Deciding the Best Cloud-Based Solution 5. Applying a Microservice Architecture to Your Enterprise Application 6. Azure Service Fabric 7. Azure Kubernetes Service 8. Interacting with Data in C# – Entity Framework Core 9. How to Choose Your Data Storage in the Cloud 10. Working with Azure Functions 11. Design Patterns and .NET 5 Implementation 12. Understanding the Different Domains in Software Solutions 13. Implementing Code Reusability in C# 9 14. Applying Service-Oriented Architectures with .NET Core 15. Presenting ASP.NET Core MVC 16. Blazor WebAssembly 17. Best Practices in Coding C# 9 18. Testing Your Code with Unit Test Cases and TDD 19. Using Tools to Write Better Code 20. Understanding DevOps Principles 21. Challenges of Applying CI Scenarios 22. Automation for Functional Tests 23. Answers 24. Another Book You May Enjoy
25. Index

Understanding unit and integration tests

Delaying the application testing until immediately after most of its functionalities have been completely implemented must be avoided for the following reasons:

  • If a class or module has been incorrectly designed or implemented, it might have already influenced the way other modules were implemented. Therefore, at this point, fixing the problem might have a very high cost.
  • The possible combination of input that is needed to test all possible paths that execution can take grows exponentially with the number of modules or classes that are tested together. Thus, for instance, if the execution of a class method A can take three different paths, while the execution of another method B can take four paths, then testing A and B together would require 3 x 4 different inputs. In general, if we test several modules together, the total number of paths to test is the product of the number of paths to test in each module. If modules are...
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at £16.99/month. Cancel anytime