Testing techniques

Session from 11:15 - 12:30. Testing techniques

This talk was kind of a discussion about testing issues in different projects. I got some key points over all arguments. Those points are more like my own quick conclusions or ideas. 

• Do not duplicate tests: Test in different layers of testing, from Unit test to acceptance test, should not bet testing the same. It should be an effort about cleaning and throwing away, if necessary, tests on the same area or functionality.

• One idea everyone agreed as a good practise was to follow a simple rule. Push the test down. It means, if the test can be and make more sense to be near the code, it is better than to write the test at acceptance or UI level.

• Modularisation looks like the right solution to many problems about testing. If developers develop project as a composition of modules or components, it looks like the over all project and its parts can be more easily tested. This could be seen as an extension of the TDD approach, where nowadays developers are encouraged to use dependency injection in order to get more testable code. To me looks like I.T engineering needs to copy from the formal manufacture engineering. Like cars, hardware, construction, etc... All them build components, tested separately and with a clear and simple interface. Then the final product is a simple composition of that parts. Why can not we simply do this in software?

• Related with the last point. Can we develop self testable (validate on the fly) components? Same as when we start the car it dose a self checking, why do not copy this in software. If we use a library. The first time the library is called and loaded on memory could perform a self checking of its environment. Should this be standardized in some way to make sense to all developers and engineers involved?

• Did you see a car builder creating a test before assembling the car door? If software methodologies get better defined about how to do things, the tests could be performed automatically or simply implicitly in the process, like any other manufacturing sector.I am totally agree that tests are good. However, to me looks still strange thing to do. At the end test should be done by a specialist in my opinion. If I write a silly test and my code pass the test, does it means my code is ready to interact with the world? Did I cover all possible usages of my code? It is too undefined to me. Yes I know it comes clear with more experience, but what happens until I get that experience? Should I release any code? Looks to me that the experience of those experts should be implicit in the methodology to develop each kind of project. In my opinion, creating the architecture that supports well adding new tests on the key points of the project, is the solution to develop agile software.

• Final conclusion. Maybe the next step for software architects, lead developers, engineers is to define methodologies that allow to develop code with implicit testable points. The first part of this is the dependency injection, what is the next step?

Posted by Marc Andreu Fernàndez.