<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testing on Cedric Bail</title><link>http://bluebugs.github.io/tags/testing/</link><description>Recent content in Testing on Cedric Bail</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 09 Nov 2024 14:20:32 -0700</lastBuildDate><atom:link href="http://bluebugs.github.io/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Tests Debt</title><link>http://bluebugs.github.io/blogs/tests-debt/</link><pubDate>Sat, 09 Nov 2024 14:20:32 -0700</pubDate><guid>http://bluebugs.github.io/blogs/tests-debt/</guid><description>&lt;p>Tests should help you release code faster and with confidence. Yet, for many developers, testing has the opposite effect, creating delays and frustration. Here, I&amp;rsquo;ll explore common pitfalls in testing and suggest better practices to make tests truly beneficial.&lt;/p>
&lt;p>We have all heard that we need to have more tests and that we should have as close to 100% tests coverage as possible. Despite this effort, we still encounter bugs. We still do manual testing and overall a lot of developers do not trust their tests to actually catch anything useful. Why is that?&lt;/p></description></item></channel></rss>