Unit testing is essential in order to ensure that your code does what it’s supposed to do.

But, as much as Typemock is a firm believer in unit testing, well, let’s be honest — it’s not fun.

As our CEO recently put it in Dr. Dobbs, “Unit testing is like staying healthy,” argues Lopian. “Staying healthy requires best practices such as eating right and working out. Similarly, development teams need the right practices in order to innovate faster. Just as it’s hard to start working out, many find it’s hard to unit test and thus stop — despite its well-known benefits”

But unit testing frameworks have many problems.

Some of them include:

1. Lack of Automation – Yes, you can write manual tests and do everything manually. You can also code in Notepad or another text editor. For some, that’s fine – witness the text editor wars in Linux – but others prefer a robust IDE and toolkit. Automatic unit testing saves time, allows for more robust testing,  and allows for tests to be run repeatedly. But even many automatic unit testing frameworks, like xUnit, or mocking-only frameworks don’t let you test much of your code unless you go 100% by the book with excellent design. Most of us simply don’t have code that can be adequately tested by even the most robust open-source frameworks, leaving us (and our business or product) vulnerable to bugs and technical debt.

2. Focus on test instead of code – The goal is working code, delivered on time. But, too often we forget this, focusing on our tests. But, this allows a disconnect between our test and our code. When a test fails, what does that mean for my code? When it passes, how do I translate that into working software?

Frequently, while we know that a test failed, we don’t always know where the error is. This makes it harder to achieve our goal – getting code out in time that just works.

3. Takes too much time – In our high-stakes development environment, frequently understaffed and overloaded, every second counts. Sometimes, we’re also tempted to shortcut now and save time up front – of course we’ll pay for that later but later is abstract when your boss is breathing down your throat. And, yes, even when you have the luxury of doing TDD by the book on greenfield code, it still takes time up front (of course it will save you time overall, but when the release is due, try telling that to your boss).

Currently, most unit testing frameworks run your entire code every time you make a minor change. If you’ made a minor change, you still need to rebuild your code from scratch. That’s time that you just don’t have when your code is overdue. Each change takes time and seconds turn into minutes and hours.

Frameworks need autocomplete – shaving time – and to just run the code that changed.

4. Weak mocking – Require TDD and good design first – can’t deal with legacy code – Simple greenfield code is a nice fantasy but it’s not most projects. What is needed is a framework that can mock complex legacy code, privates, statics, etc. Most frameworks don’t offer powerful mocking or the ability to test legacy code, new code, or even unwritten code.

5. Coverage – Too many frameworks don’t let you know what’s covered and what’s not. Yes, as Uncle Bob said, coverage is not the most important or only metric and 100% code coverage may not always be the ideal.

But, too often, we don’t know what code is covered and what code is insecure.

 

Leave a comment – what are some things you find lacking with unit testing frameworks. Feel free to tweet as well using hashtag #tddfail

 

It’s time for a change.

Luckily, change is coming.

Stay tuned.

Can’t wait? Discover unit testing tools and practices this Wednesday and enter the raffle to win an Isolator license.

Want more webinars? Sign up!

Typemock is hosting a webinar about how to test dependencies and legacy code. The webinar will be on Wednesday February 8 at 8:30 PM (20:30) India Standard Time.

You may have already started unit testing or at least understand the basics. But there’s one large obstacle that stands in your way: dependencies. Most code was not written to be easy to test. How can you test dependencies? Join this webinar and learn different methods and tools that help create unit tests to test dependencies and legacy code.

Learn:

• Why you are writing legacy code

• Hand rolled mocks

• Mocking frameworks

• What makes a good unit test

This webinar is intended for .NET developers interested in automated unit testing who want to learn how to develop better code.

You can also win a Typemock Isolator license or t-shirt. You must attend for the chance to win

To sign up: http://www.typemock.com/unit-testing-dependencies-and-legacy-code

The Sonar team is proud to announce the release of Sonar 2.13. This new version includes 60 improvements, bug-fixes and also some new features that we believe are worth stopping your daily work for a couple of minutes to check out : ability to create manual reviews / violations anywhere in the code, ability to create action plans and an extended search engine.

Extended search engine

The search engine will now return not only projects but also modules, package and files. A picture is worth a thousand words :

Add a review on any piece of code

Whenever a quality defect is detected “manually”, the person who detected it has the ability to inject a violation directly into Sonar:

The related violation is then displayed within the source code and will be accounted for in metrics after the next analysis of the project:

Action plans

Action plans can be created to group reviews together.

An action plan can be associated to each violation

And then it is possible to review progress in a widget of a dashboard

Hotpots 2.0

The previous release allowed to use hotspot widgets in its own dashboards (see Sonar 2.12 in screenshots). It’s now possible to customize, rename or even delete the default dashboard named “Hotspots”.

Time now to give a try to the new version and to read the installation or upgrade guides.

On February 2nd, 2011 the first release of Jenkins, version 1.396, was made available for public consumption. Thus marking a new beginning for many of us who had come to rely on this very versatile piece of software and wanted to see it continue to thrive.

Along with some other bug fixes, the 1.396 release of Jenkins included a very important changelog item:

Fixed a trademark bug that caused a considerable fiasco by renaming to Jenkins

On behalf of the core Jenkins team and the governance board I would like to extend a extremely large Thank You! to all of the plugin developers, bug filers, wiki page editors, book authors and the users who have helped grow Jenkins into the project it is today.

Some of the tidbits from our highlight reel:

• As of this writing there have been 54 releases of Jenkins
• Jenkins now supports writing plugins in Ruby as well as Java (more languages in the process)
• We have 7 high-speed mirrors streaming Jenkins packages to users around the world.
• There are now over 450 different plugins available for Jenkins
• Over 80 donors participated in our end of year fundraising drive
• 5 "Long Term Support" releases have been published by the Jenkins community, offering users a slower moving upgrade target (supported even further by CloudBees' Enterprise Jenkins product)
• Public project governance meetings are held and recorded (almost) every couple of weeks.
• More than 340 individuals contribute on GitHub to the project in some form or another.
• About 750 members of the developers mailing list and around 1700 on the users mailing list

There are many other impressive sounding numbers I could rattle off, but the list is far too long to be interesting.

The project isn't perfect and nor is the software, but we're off to a fine start and I hope you'll join us in making this next year of Jenkins even better than the first.

Selenium Tutorial for Beginners Selenium is an open source technology for automating browser-based applications. Selenium is easy to get started with for simple functional testing of a Web application. I can usually take a beginner with some light testing experience and teach them Selenium in a 2 day course. A few years ago I wrote a fast and easy tutorial Building Selenium Tests For Web Applications tutorial for beginners.



The Selenium Tutorial for Beginners has the following chapters:

• Selenium Tutorial 1: Write Your First Functional Selenium Test
• Selenium Tutorial 2: Write Your First Functional Selenium Test of an Ajax application
• Selenium Tutorial 3: Choosing between Selenium 1 and Selenium 2
• Selenium Tutorial 4: Install and Configure Selenium RC, Grid
• Selenium Tutorial 5: Use Record/Playback Tools Instead of Writing Test Code
• Selenium Tutorial 6: Repurpose Selenium Tests To Be Load and Performance Tests
• Selenium Tutorial 7: Repurpose Selenium Tests To Be Production Service Monitors
• Selenium Tutorial 8: Analyze the Selenium Test Logged Results To Identify Functional Issues and Performance Bottlenecks
• Selenium Tutorial 9: Debugging Selenium Tests
• Selenium Tutorial 10: Testing Flex/Flash Applications Using Selenium
• Selenium Tutorial 11: Using Selenium In Agile Software Development Methodology
• Selenium Tutorial 12: Run Selenium tests from HP Quality Center, HP Test Director, Hudson, Jenkins, Bamboo
• Selenium Tutorial 13: Alternative To Selenium

A community of supporting open source projects - including my own PushToTest TestMaker - enables you to apply your Selenium tests as functional tests for smoke testing, regression testing, and integration tests, load and performance tests, and production service monitors. These techniques and tools make it easy to run Selenium tests from test management platforms, including HP Quality Center, HP Test Director, Zephyr, TestLink, QMetry, from automated Continuous Integration (CI) tests, including Hudson, Jenkins, Cruise Control, and Bamboo.

I wrote a Selenium tutorial for beginners to make it easy to get started and take advantage of the advanced topics. Download TestMaker Community to get the Selenium tutorial for beginners and immediately build and run your first Selenium tests. It is entirely open source and free!

In a previous article, I said Test-Driven Development is a possible development workflow that incorporates Developer Testing, but Developer Testing does not necessarily only exist in Test-Driven Development (TDD). Later I pulled together this graphic I could equate all of the steps between TDD and Waterfall, but would gloss over the design phase. Then, one [...]

Want a sneak peek at what’s coming up in our labs?

Want to learn more, stay tuned for upcoming webinars in February.

The only links left now are ones currently open in tabs right now. Hurray!

• November’s SFSE was Continuous Deployment At Mozilla: slides, video
• Practical Web Test Automation is a book available in both a free and paid editions. I haven’t looked at it so can’t comment how good or bad it is.
• The Why, What and How of Software Test Automation isn’t too horrible, though I don’t like the word ‘guideline’ and of course the measurement section at the bottom is complete hokum.
• Internet Explorer for Mac the Easy Way: Run IE 7, IE8, & IE9 Free in a Virtual Machine seems a bit sketchy in terms of license legality, but…
• PageMapper is a bit of template magic to create Page Objects
• Web Consistency Testing is starting to push what can [should] be done with Selenium
• Taking Automated Tests Off The Pedestal erm, takes automation off its pedestal
• Monkey-Patching iOS with Objective-C Categories Part I: Simple Extensions and Overrides is a technique I haven’t seen before.
• A Tool’s Tale would be better with Sebastian in front of it, but is still useful as a standalone deck.
• Introducing the software testing ice-cream cone – Dangit! Now I want ice cream.

And my post this edition is WebDriver and Meta Tags.

When Noah Sussman asked me to give a Code as Craft Technology Talk last week when I was consulting for Etsy I immediately said yes. However, I was a bit surprised when the talk was announced under the title "An Evening with Sebastian Bergmann". When I read that title the first time, it was just minutes after Arne, Stefan and I had talked about one of our favourite scenes from "A Knight's Tale":

Chaucer: I'm a writer.

Wat: A what?

Chaucer: A wha- a what? A writer. You know, I write, with ink, and parchment. Geoffrey Chaucer's the name, writing's the game. You've probably read my book? The Book of the Duchess? No? Well, it was allegorical.

Roland: Well, we won't hold that against you, that's for every man to decide for himself.

Just like with a talk that I gave last year, I suddenly had a chain of associations in my head that I just had to follow. And down the rabbit hole I went once more ...

Hi! I have no idea why this talk is titled "An Evening with Sebastian Bergmann". I hope that this evening will turn into an interesting discussion about PHPUnit and all things testing. To break the ice, and to not appear completely unprepared, I came up with the following slides ...

So I recently talked with my friends Arne and Stefan about the movie "A Knight's Tale". Somehow the idea stuck in my head that a variation of that title might be a good idea for a talk of mine. After dismissing "A Fool's Tale" I arrived at "A Tool's Tale". So that's what we're stuck with and what I am going to try right now ...

 

 

 

What I just did was a variation on how Geoffrey Chaucer introduces himself in the movie.

Some time in 2001 I started to work on PHPUnit because I wanted to have something like JUnit for PHP. The initial "port" was completed within one weekend. The code was ugly because I had to emulate exceptions which PHP 4 did not have. On November 27th 2001 I checked the code into cvs.php.net.

A lot has changed since 2001. Hopefully not very many developers are still stuck with PHP 4. As of PHPUnit 2.0, which was released on July 14 2004, the day after PHP 5.0.0 was released, PHP 5 is required to run PHPUnit.

PHPUnit is neither the only testing framework nor the only quality assurance tool for PHP. Over the last years a nice ecosystem of static analysis tools started to grow.

I get this question a lot: why do only Germans work on tools that tell me that my code is bad? I do not have an answer for this, sorry. But the statement is also not true: PHP_CodeSniffer is not developed by a German.

PHP has changed and so the have the tools we use to write and maintain code. In 2006 the PHPUnit code was migrated from CVS to Subversion ...

... and in December 2009 from Subversion to Git and GitHub.

PHPUnit is no longer one big monolithic package. It has been refactored to components that are being reused by other testing frameworks, for instance. Unfortunately, this refactoring was not without problems.

PHPUnit gets more and more convenience functionality. Here are a couple of examples:

 

 

 

Tests can be written, both unintentionally and intentionally, in bad ways. Bad tests can lie. They can give you a false sense of security by reporting that something is tested when it really is not.

This is why I started iplementing coutermeasures against bad tests such as the (ultimately useless but still interesting) assertion counting ...

... as well as the strict execution mode.

There is code in PHPUnit that I am not proud of. I am trying to make the world a better place by eliminating one singleton at a time, for instance. Unfortunately, cleaning up code sometimes breaks things. Contrary to what a popular opinion on Twitter is, I do not like breaking backwards compatibility in PHPUnit and try really hard to avoid it.

This is a "good" example of such a backwards compatibility breakage. It happened in PHPUnit 3.6 because I eliminated a Singleton. Had I known that many developers used this API (instead of the XML configuration file) to set up a code coverage blacklist or whitelist I would probably not have done the change. If more people would have tested the release candidates leading up to PHPUnit 3.6 they could have told me ... oh well.

At this point the "Evening with Sebastian Bergmann" turned into the interesting discussion I had hoped for.

watir-webdriver 0.5.2 has been released.

Please note that watir-webdriver 0.5.0 brings some backwards incompatible changes:

• Watir::Select#selected_options no longer returns array of strings, but array of Watir::Option objects
• Finding elements by :class now matches partial class attributes.

Additionally, watir-webdriver 0.5.1 removes the following deprecated methods:

• element_by_xpath replaced by .element(:xpath, '...')
• elements_by_xpath replaced by .elements(:xpath, '...')

And deprecates the following methods:

• Browser#clear_cookies – replaced by Browser#cookies API

Install it with

gem install watir-webdriver

As usual:

• see build history at travis-ci.org/#!/watir/watir-webdriver/builds (wait for a few seconds until older builds appear)
• see all the changes at github.com/watir/watir-webdriver/commits/master/
• updated API documentation is at rubydoc.info/gems/watir-webdriver

Look! A light at the end of the tunnel!

• ASP.NET MVC + Selenium + IISExpress – You don’t see too many Windows how-to’s. Not sure if they just don’t get tweeted about or is more a sign of that community.
• Write Logs for Machines, use JSON is a nice idea. I wonder if (when) the major CI containers will land on a pseudo-standard for consuming JSON
• Remote File Upload using Selenium 2′s FileDetectors shows yet another area I need to figure out in WebDriver (not Selenium 2 as Santi so stubbornly referred to it as
• Janky is GitHub’s CI server. Seems like this is the current cool route; that is, implementing your own rather than building off of one of the major existing ones. Which I suppose makes sense.
• From Dependent Tests to Independent Tests to Independent Assertions has a nice refactoring trick to clean-up your scripts
• I’ve posted how to inject Sizzle into your WebDriver scripts at least once, and here is another time. Injecting the Sizzle CSS selector library
• And if Sizzle isn’t your thing, WebDriver Plus has JQuery-esque DOM Traversing
• Important notice regarding Java packages in Partner archive is something to keep in mind if you want to run the Selenium Server on Ubuntu
• Looks like ShingingPanda is the Python equivalent of CloudBees, and has instructions on how to get Selenium running on it in ShiningPanda is Selenium ready!
• Articles that lead in with Boy. That was a headache. are usually good ones to link to. WebDriver, Webdriver, and more web driver. This one is about the WebDriver iOS driver.

And today’s post of mine is WebDriver and Cookies which explains how, well, cookies and webdriver play together.

It’s that time of year when the US president gives the annual State of the Union. Since Mr. Obama did not mention unit testing, (I suspect because of homeland security issues) I thought I’d give you my view of where unit testing is in the beginning of 2012.

• Unit testing and TDD are getting traction. More people understand the value, and more developers see that testing is part of what makes them professional.
• Unit testing has a wide acceptance across technologies. Developers who unit test, do it across languages.
• More and more, we regard unit testing as a skill, rather than a development methodology. As any skill it is learned, experienced, improved and mastered. Some people go all the way, some people start and turn back, never to return.
• Mastering unit testing requires discipline. Discipline begets professionalism. Those things go together, and why you’ll find both traits in successful developers.
• A lot more people do not unit test than those who do. That’s because unit testing is still hard. The tools are mostly there (depending on the technology and language). Successful developers do not just master tools, but also apply their experience on how to write tests, organize them and maintain them. This is not taught anywhere, and most developers don’t have the mentors, drive or discipline for the long haul.
• In many organizations that unit test, it’s not really wide spread. A few teams do it, the rest don’t. In order to do an organizational change, you’ll need the skilled people in place to drive the rest of the teams. Since there aren’t many of those around, the organization adoption is very slow.

So what’s next?

The slow adoption rate will change based on two things: better tools that make it easier to test and fix bugs, and the availability of many people to drive teams toward adoption. Typemock will drive the first part (I’ve already alluded to new features in Isolator V7 and that’s just the beginning) but the community needs to do the evangelizing and education that will get more people into the unit testing circle. With more people around we can turn the trickle into a torrent.

And then nobody will have bugs! But I’ll leave that to next year’s State of the Union.

Beg to differ? Write down you’re assessments and predictions in the comments!

No. Really. A Smattering every day this week and I’ll have the link queue cleared.

Go!

• Mentioned in #74, Automating Web Performance data collection with BrowserMob Proxy and Selenium is more than just a link to GitHub
• Of course you are using the excellent Requests module rather than urllib2 which ships with Python; but are you using envoy instead of subprocess?
• Grabbing Screenshots of Failed Selenium Tests uses some JUnit magic. Also, gotta love articles that end in How easy was that?!
• Rackspace Open Sources Dreadnot – Aside from an excellent name, its based on Deployinator which is pretty darn cool and I saw in action the other week
• Geeks and Repetitive Tasks. Umm. Yup.
• Officially Introducing “SST” that this link is here is evidence that I should go through the queue from the top of the list. There was a screencast on SST in #75.
• 7 Deadly Sins of Automated Software Testing – nice article and as someone who has done linocut before, that’s an impressive print that is featured.
• Introducing Selenose is a Selenium plugin for Nose
• Two useful Firefox plugins I stumbled on are FirePath and Firecookie
• Sorting a million 32-bit integers in 2MB of RAM using Python is this edition’s geeky investigation

One thing I have done in these Smatterings is to not link to my own stuff, but am going to start linking to an article or two at the bottom of the Smatterings (unless there is general community backlash against the idea).

• In Introducing PHPWebDriver I unleash some code upon the world

Want to help Typemock and the unit testing community.

Contribute to Typemock’s latest project.

We’re currently developing a brand new way to do unit testing – it’s a whole new perspective.

I can’t tell you what it’s going to do but sign up for our upcoming webinars to learn more.

We need you to choose. Which icon do you want to see?

Version A:

Version B:

Which Icon Do You Want?
Leave your thoughts in the comments or in the survey.

By Gil Zilberfeld, Product Manager, Typemock, February 1, 2012

When: 10:00 AM ET, 3:00 PM UK, 5:00 PM Israel – Click here to see when the webinar is in your time zone.

Software testing isn’t just a task for QA. In order to prevent bugs and release quality code to market, you also need developer testing, including unit testing.

Learn the difference between unit tests, integration tests, manual tests and acceptance tests.

Learn:

• QA vs. Developer Testing
• Benefits of unit testing
• xUnit Frameworks
• The difference between unit testing and test driven development (TDD).

Join this webinar to learn what you need to know in order to start testing today. You may also have a chance to win an Isolator license – but only if you attend.

Click here to sign up

If your current testing framework is not supported, you can create your own namer to allow you to use it.
Check out this namer for ideas how to make your own.

SOA Testing with Open Source Test Tools PushToTest helps organizations with large scale Service Oriented Architecture (SOA) applications achieve high performance and functional service delivery. But, it does not happen at the end of SOA application development. Success with SOA at Best Buy requires an Agile approach to software development and testing, on-site coaching, test management, and great SOA oriented test tools.

Distributing the work of performance testing through an Agile epoc, story, and sprints reduces the testing effort overall and informs the organization's business managers on the service's performance. The biggest problem I see is keeping the testing transparent so that anyone - tester, developer, IT Ops, business manager, architect - follows a requirement down to the actual test results.

With the right tools, methodology, and coaching an organization gets the following:

• Process identification and re-engineering for Test Driven Development (TDD)
  
• Installation and configuration of a best-in-class SOA Test Orchestration Platform to enable rapid test development of re-usable test assets for functional testing, load and performance testing and production monitoring
• Integration with the organization's systems, including test management (for example, Rally and HP QC) and service asset management (for example, HP Systinet)
• Construction of the organization's end-to-end tests with a team of PushToTest Global Professional Services, using this system and training of the existing organization's testers, Subject Matter Experts, and Developers to build and operate tests
• On-going technical support

On-Site Coaching Leads To Certification
The key to high quality and reliable SOA service delivery is to practice an always-on management style. That requires on-site coaching. In a typical organization the coaches accomplish the following:

• Test architects and test developers work with the existing Testing Team members. They bring expert knowledge of the test tools. Most important is their knowledge of how to go from concept to test coding/scripting
  
• Technical coaching on test automation to ensure that team members follow defined management processes
  

Cumulatively this effort is referred to as "Certification". When the development team produces quality product as demonstrated by simple functional tests, then the partner QA teams take these projects and employ "best practice" test automation techniques. The resulting automated tests integrate with the requirements system (for example, Rally), the continuous integration system, and the governance systems (for example, HP Systinet.)
Agile, Test Management, and Roles in SOA
Agile software development process normally focuses first on functional testing - smoke tests, regression test, and integration tests. Agile applied to SOA service development deliverables support the overall vision and business model for the new software. At a minimum we should expect:

1. Product Owner defines User Stories
2. Test Developer defines Test Cases
3. Product team translates Test Cases into soapUI, TestMaker Designer, and Java project implementations
4. Test Developer wraps test cases into Test Scenarios and creates an easily accessible test record associated to the test management service
   
5. Any team member follows a User Story down into associated tests. From there they can view past results or execute tests again.
6. As tests execute the test management system creates "Test Execution Records" showing the test results
   

Learn how PushToTest improves your SOA software development life cycle. Click here to learn how.

PIT is a fast mutation testing system for Java that makes it possible to test the effectiveness of your unit tests.

You can think of mutation testing as either as an automated test of your tests, or as a much more in depth form of code coverage.

PIT runs your tests against automatically modified versions of your application code. When the application code changes, it should cause a test to fail. If a test does not fail it may indicate an weakness in the suite.

See http://pitest.org for further details.

Easy question, right? You DEBUG.

Not so fast, my friend. Actually, if you think about it, debugging is not so fast. Pretty slow, really. I’d rather do as quickly as possible.

Let’s get back to the question: A test (or three) failed, because you’ve changed the production code. How do you fix it?

Tests’ primary role is to notify you that something’s broken. The have a secondary role, which we don’t really think about often: help us fix that bug as quickly as possible.

So what do we do when a test fails?

Naturally, we look at the name of the test. This is the first clue. And why you shouldn’t name your test “Test33”. The test’s name should explain what the scenario actually tested and the expected result.

The next step would be thinking: What code did I touch? (Or, in other words: What shouldn’t have I touched?). If we run our tests regularly, like every few minutes, we’d probably know. If it’s more like a few hours or days, we won’t.

But that’s not all.

We also look around for tests in the vicinity of the tests that failed. Why are those tests passing, while others are failing? What different scenarios do they cover?

We think about all three, and try to make sense of what just happened. We want to fix the bug as quickly as possible.

So wouldn’t it be great to have something like this pop up automatically on the production code that you’ve recently changed, when you build your code?

Yes it would.

And it’s coming soon in Isolator V7. Stay tuned.

Post ten links, find seven more to add to the queue.

• Selenium Page Objects and Abstraction is one person’s attempt at writing down how they describe POs
• Running Geb specs using a separate driver profile to test mobile views in Grails shows how to create a custom Firefox profile in WebDriver
• Django and Selenium on Jenkins/Hudson (Headless) is yet another tutorial around xvfb but has a trick at the end I don’t think I’ve seen
• Python’s concurrent.futures is today’s analysis of building a script
• Browser Sedimentation has an outstanding diagram of whats what in a browser. I know I’ll be referring back to it.
• Airbrake seems like it would be useful — especially once you start parallelizing execution across instances
• Whole-team Test Automation: Making the Move offers some tips for implementing it on your team — at least according to the blurb at the top
• Hey look! Another xvfb think. Can we please just put this into the Se docs already?
  
• Selenium Webdriver, Perl, and Saucelabs also acts as a sample for the (a) Perl WebDriver binding too
• Convincing management that cooperation and collaboration was worth it – dark launches, config flags, oh my.