Got a demo coming? Write automated tests that simulate the steps you'll be taking. Then print out your test suite, and use it like a script.
With these steps, we will see how to write our management demo script in a runnable fashion.
- Create a new file called
recipe66.pyto store the test code for our management demo. - Create a
unittesttest scenario to capture your demo. - Write a series of operations as if you were driving the application from this automated test.
- Include asserts at every point where you will vocally point out something during the demo.
import unittest from network import * from springpython.database.factory import * class ManagementDemo(unittest.TestCase): def setUp(self): factory = MySQLConnectionFactory("user", "password", "localhost", "recipe62") self.correlator = EventCorrelator(factory) dt = DatabaseTemplate(factory) sql = open("recipe62_network.mysql").read().split(";") for statement in sql: dt.execute(statement + ";") def test_processing_a_service_affecting_event(self): # Define a service-affecting event evt1 = Event("pyhost1", "serverRestart", 5) # Inject it into the system stored_event, is_active, updated_services, updated_equipment = self.correlator.process(evt1) # These are the values I plan to call # attention to during my demo self.assertEquals(len(updated_services), 1) self.assertEquals("service-abc", updated_services[0]["service"]["NAME"]) self.assertEquals("Outage", updated_services[0]["service"]["STATUS"]) if __name__ == "__main__": unittest.main() - Run the test suite by typing
python recipe66.py.
This recipe is more philosophical and less code based. While the concept of this recipe is valuable, it is hard to capture in a single nugget of reusable code.
In this test case, I inject an event, process it, and then confirm what it impacts. This test case is headless, but our demo probably won't be. So far in this chapter, we haven't built any user screens. As we develop user screens, we need to ensure they call the same APIs as this automated test.
Given this, we are setup to use the screens to define the same event shown in the test. After the event is digested, another screen will probably exist that shows current service status. We would expect it to reflect the update to Outage.
During our management demo, we will then point out/zoom in to this part of the screen and show how service-abc switched from Operational to Outage.
If the screens are built to delegate to this underlying logic, then the screen logic is little more than components put together to display information. The core logic being tested maintains its headless and easy-to-test nature.
Our code sample isn't complete, and wouldn't amount to more than a one minute demo. But the concept is sound. By capturing the steps we plan to execute in our demo in a runnable form, our management demo should go off without a hitch.
Tip
Did I say without a hitch? Well, demos rarely work that well. Doesn't something about management appearances cause things to break? At one time, I began prepping for a senior management demo a month in advance using this recipe. I uncovered and subsequently fixed several bugs, such that my demo worked flawlessly. Management was impressed. No promises, but sincerely making your demo 100 percent runnable will greatly increase your odds.
What is the secret to this recipe? It seems to be a bit short on code. While it's important to make the demo 100 percent runnable, the key is then printing out the test and using it like a script. That way, the only steps you are taking have already been proven to work.
If your manager likes to ask lots of what-if questions that pulls you off script, then you are sailing into uncharted territory. Your odds for a successful demo may drop quickly.
You can politely dodge this by capturing their what-ifs for a future demo and try to keep the current one on track. If you take the plunge to try other things out, realize the risk you are taking.
Tip
Don't be afraid to promise a future demo where you will travel down the path requested instead of risking it in this demo. Managers are actually pretty open to accepting a response like: "I haven't tested that yet. How about another demo next month where we cover that?". Failed demos leave a bad taste with management and put your reputation in jeopardy. Successful ones have an equally positive effect to your reputation as a developer. Management tends to have a more optimistic view of seeing 70 percent of the system succeed 100 percent rather than viewing 100 percent of the system succeed 70 percent.
This is where the line between engineer and manager needs to be observed. While managers want to see what's available, it is our job to show them what is currently working and give an accurate status on what is and isn't available. Asking to see something we haven't tested yet definitely warrants pushing back and telling them such a demo isn't ready yet.