{"href":"https://api.simplecast.com/oembed?url=https%3A%2F%2Fbettersoftwaredesign.simplecast.com%2Fepisodes%2F84-ys43eKDs","width":444,"version":"1.0","type":"rich","title":"84. O implementacji testów backendu i architekturze otwartej na testowanie","thumbnail_width":300,"thumbnail_url":"https://image.simplecastcdn.com/images/e37e236c-1fa8-459a-81e9-cd3548888657/98559e66-04c8-4cf7-9e2b-1647875b208f/2-2500px.jpg","thumbnail_height":300,"provider_url":"https://simplecast.com","provider_name":"Simplecast","html":"<iframe src=\"https://player.simplecast.com/b8b44e56-8ba4-42bc-b2f9-75429cc2fa89\" height=\"200\" width=\"100%\" title=\"84. O implementacji testów backendu i architekturze otwartej na testowanie\" frameborder=\"0\" scrolling=\"no\"></iframe>","height":200,"description":"Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction..."}