<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Testing on Brave New Geek</title><link>https://bravenewgeek.com/tag/testing/</link><description>Recent content in Testing on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 17 Apr 2018 12:46:22 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>More Environments Will Not Make Things Easier</title><link>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</link><pubDate>Wed, 11 Apr 2018 15:49:47 -0500</pubDate><guid>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</guid><description>&lt;p&gt;Microservices are &lt;a href="https://bravenewgeek.com/service-disoriented-architecture/"&gt;hard&lt;/a&gt;. They require extreme discipline. They require a lot more upfront thinking. They introduce integration challenges and complexity that you otherwise wouldn’t have with a monolith, but service-oriented design is an important part of scaling organization structure. Hundreds of engineers all working on the same codebase will only lead to angst and the inability to be nimble.&lt;/p&gt;
&lt;p&gt;This requires a pretty significant change in the way we think about things. We’re creatures of habit, so if we’re not careful, we’ll just keep on applying the same practices we used before we did services. And that will end in frustration.&lt;/p&gt;</description></item><item><title>Benchmark Responsibly</title><link>https://bravenewgeek.com/benchmark-responsibly/</link><pubDate>Fri, 02 Jan 2015 14:53:22 -0600</pubDate><guid>https://bravenewgeek.com/benchmark-responsibly/</guid><description>&lt;p&gt;When I posted my &lt;a href="http://www.bravenewgeek.com/dissecting-message-queues/"&gt;Dissecting Message Queues&lt;/a&gt; article last summer, it understandably caused some controversy.  I received both praise and scathing comments, emails asking why I didn’t benchmark X and pull requests to bump the numbers of Y. To be honest, that analysis was more of a brain dump from my own test driving of various message queues than any sort of authoritative or scientific study—it was &lt;em&gt;far&lt;/em&gt; from the latter, to say the least. The qualitative discussion was pretty innocuous, but the benchmarks and &lt;a href="https://github.com/tylertreat/mq-benchmarking"&gt;supporting code&lt;/a&gt; were the target of a lot of (valid) criticism. In retrospect, it was probably irresponsible to publish them, but I was young and naive back then; now I’m just mostly naive.&lt;/p&gt;</description></item></channel></rss>