ContinuousIntegration
From APIDesign
JaroslavTulach (Talk | contribs)
(New page: There is nothing wrong on having your own ContinousIntegration server like Jenkins or Hudson set up. In fact having it can only help quality of your project. As Chapter 10 ...)
Next diff →
Revision as of 11:39, 3 April 2018
There is nothing wrong on having your own ContinousIntegration server like Jenkins or Hudson set up. In fact having it can only help quality of your project. As Chapter 10 of TheAPIBook explains, Chapter 10 is the sole of good frameworks and the most important part of good projects.
Can't Test Everything!
On the other hand, people get so used to this comfortable safety net provided by the by ContinuousIntegration systems that they tend to forget there is also something behind the horizon. QA departments are well aware of the fact that regardless of the amount of CodeCoverage (btw. how much CodeCoverage is enough?), there can always be errors visible to end users. The situation is even more complicated when it comes to API Design.
A common advice would be to increase your CodeCoverage or add integration tests to verify the real workflow. The biggest problem when designing an API of a framework however is: you can't run all the users code! You don't have it, you don't even know about it. When your framework is successful, then running all projects that use your API wouldn't even scale.
Observe the Visible
As such one has to do something else. Rather than testing all the dependent code, one has to make sure the externally observable aspects of your framework as stable - e.g. they don't share like the amoeba in the AmoebaModel. What does that mean?
Follow
