Wiki source code of Testing

Version 2.6 by chrisby on 2023/05/29 11:43

version	line-number	content
2.6	1	=== Foreword ===
	2
	3	(% style="text-align: justify;" %)
	4	The chapters presented here are a concise summary of more theoretical and high-level knowledge. It is recommended that you are familiar with writing very basic tests and mocks, and understand the concepts of polymorphism and [[dependency injection>>doc:Software Architecture.Dependency Injection.WebHome]].
	5
	6	=== ===
	7
	8	=== General ===
	9
	10	* Ultimate Goal of testing: Reduce costs and increase productivity.
2.2	11	* Definition 'Production Code': Code that provides functionality to meet project requirements.
	12	* Definition 'Test Code': Often referred to as "tests", it is written to verify the correct functionality of the production code.
1.1	13
2.3	14	=== ===
	15
1.1	16	=== Benefits of Testing ===
	17
	18	* Quality Assurance
	19	Automated Testing**: Minimizes the need for human source code checking or manual testing, providing a cost-effective way to ensure continuous quality assurance and the correct functioning of software at all times.
2.1	20	Early Feedback**: Tests provide immediate bug feedback. This is especially true for detecting accidentally introduced bugs caused by code changes. The earlier bugs are detected, the cheaper they are to fix.
1.1	21	Bug Location Detection**: Tests identify bug locations, saving debugging time.
	22	* Testable Design
	23	** Writing tests automatically enforces design best practices, resulting in a 'testable design' and higher quality code. Good code and architecture are testable, and vice versa.
	24	* Documentation
2.3	25	** Tests serve as the most current form of code documentation, capturing the expected behavior of the production code in its present state.
	26
	27	=== ===
	28
	29	=== What should be tested? ===
	30
2.6	31	(% style="text-align: justify;" %)
2.3	32	Every functionality you expect the software to provide at any moment. You should test:
	33
2.4	34	* Use Cases
2.5	35	** Use cases defined in project requirements
	36	** Lower-level use cases derived from the high-level project use cases. For example, expected behavior of functions, classes, modules, and components that users of the software do not see.
2.3	37	* Border cases that could theoretically always occur, such as maximum/minimum values, nulls, invalid input, nulls, negative numbers, empty lists, values with special meaning, exceptions, etc.