What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, and it provides the authors analytical data about your interactions with their content.
Embed code for: SOLID&UnitTesting
Select a size
Presentación usada en el evento dotnetters del 31/03/2017
Principios SOLID y Unit Testing
para el desarrollo de software mantenible, extensible y testable
Team Leader en Ibercaja Vida
Desarrollador y facilitador técnico en
Unit Testing - ¿Qué es?
Unit Testing - ¿Para qué?
Unit Testing - ¿Cómo?
Unit Testing - Productividad
Y esto, ¿afecta a la productividad?
Unit Testing - ¿Cómo deben ser las pruebas?
Unit Testing - ¿Qué hay que probar?
RIGHT - BICEP
Are the results RIGHT?
¿Los resultados son CORRECTOS?
Are all BOUNDARY conditions correct?
¿Se comporta bien en CONDICIONES LÍMITE?
Comprobación mediante LÓGICA INVERSA
Can you check INVERSE relationships?
COMPROBACIONES CRUZADAS con otros métodos
Can you CROSS-CHECK results using other means?
Forzar CONDICIONES DE ERROR
Can you force ERROR CONDITIONS to happen?
¿El RENDIMIENTO es aceptable?
Are PERFORMANCE characteristics within bounds?
Unit Testing – Condiciones Límite
Single responsability principle
Solo una razón de cambio
Rafa solution principle
Prepara tu solución para poder aplicar SOLID
Open – Close principle
Liskov substitution principle
Diseño por contrato
Derivado == clase base
Interface segregation principle
Interfaces específicos a una finalidad
Dependency inversion principle
Desacoplar las clases
R-SOLID CASO USO FOTOS
1ª refactorización (2 formas)
Asignación de nombre a Fotos digitalizadas Carpeta única
SD Nueva carpeta, Nueva carpeta (1), Nueva carpeta (2), varios, etc (Varios más grande que FASE 1)
Cámara digital Reorganizar en carpetas. Tiempo invertido
Regresión mismos errores
Tiempo Fase 0 Fase 1 Fase 2 Fase 0
2 formas + saco
R-SOLID – Fase 4
FASE 4.- GUIAS NO REGLAS
R-SOLID – Fase 4 - Varios
R-SOLID – Ejemplo solution
Nacieron como una reacción a los design smells. La violación de algún principio del diseño orientado a objetos.
Open – Closed principle
No son reglas, son guías
Piensa una estructura que se adapte a tus necesidades y que encaje con los principios SOLID
De la Wikipedia: https://en.wikipedia.org/wiki/Unit_testing
Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. It forms the basis for component testing.
Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when test cases fail, makes it less clear which component is causing the failure. See also Fakes, mocks and integration tests. Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher-quality unit that is also more maintainable.
Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. The objective in unit testing is to isolate a unit and validate its correctness. A manual approach to unit testing may employ a step-by-step instructional document. However, automation is efficient for achieving this, and enables the many benefits listed in this article. Conversely, if not planned carefully, a careless manual unit test case may execute as an integration test case that involves many software components, and thus preclude the achievement of most if not all of the goals established for unit testing.
To fully realize the effect of isolation while using an automated approach, the unit or code body under test is executed within a framework outside of its natural environment. In other words, it is executed outside of the product or calling context for which it was originally created. Testing in such an isolated manner reveals unnecessary dependencies between the code being tested and other units or data spaces in the product. These dependencies can then be eliminated.
Using an automation framework, the developer codes criteria, or an oracle or result that is known to be good, into the test to verify the unit's correctness. During test case execution, the framework logs tests that fail any criterion. Many frameworks will also automatically flag these failed test cases and report them in a summary. Depending upon the severity of a failure, the framework may halt subsequent testing.
As a consequence, unit testing is traditionally a motivator for programmers to create decoupled and cohesive code bodies. This practice promotes healthy habits in software development. Design patterns, unit testing, and refactoring often work together so that the best solution may emerge.
Conformance—Does the value conform to an expected format ?
Ordering—Is the set of values ordered or unordered as appropriate ?
Range—Is the value within reasonable minimum and maximum values ?
Reference—Does the code reference anything external that isn’t under direct control of the code itself?
Existence—Does the value exist (e.g., is non-null, nonzero, present in a set, etc.)?
Cardinality—Are there exactly enough values?
Time (absolute and relative)—Is everything happening in order? At the right time? In time?
are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such pro