In Part 1 I introduced the idea of a feature toggle library, and I wrote that the starting point for Clarion development should not be the data dictionary. In many cases the data dictionary comes at the very end of the process.
Yes, that flies in the face of almost everything we've learned about Clarion. But that's only because we've been so fixated on what Clarion does best: browse and form business apps.
Think about where you spend most of your time. Is creating browses and forms? No, because Clarion does that so well. You spend your time writing code that models various kinds of business processes that don't fit neatly into the browse/form paradigm.
The right fit for TDD
If the data dictionary doesn't come first, what does? There are a lot of different answers to that question, depending on what kind of application you're developing, the stage of development, and the scope of the requirement. Unless you value trial and error highly and enjoy throwing away most of your code, you're going to want to do some design up front.
For small-sized (and sometimes medium-sized) business modeling tasks I regularly turn to Test Driven Development, or TDD. As the name suggests, this kind of development begins with writing tests. Of course a main benefit of TDD is that you end up with tests at the end of the process, and you can use those to continually validate the behavior of your code as you go on to maintain it. But I've found TDD equally useful as a design aid.
When I begin with a test I'm forced think about how I want to use my code. This short-circuits my natural tendency to jump to the implementation, and writing the implementation at the start is an investment, and the more I invest in some code the less likely I am to throw it away and start over, even if it turns out my initial implementation reflects some poor design choices.
TDD lets me think about my code at a high level of abstraction.For instance, here's a test that sketches out how I might detect whether a feature is enabled or disabled (with the test setup code omitted):
It's really important to understand that at this point the code doesn't even compile. I don't have a class called CML_FeatureToggle_Toggle. Once I'm happy with how my test code looks, the next step will be to stub out the class and methods so the code compiles. Of course at that point the test will fail; the final step is to write code so the test passes. But I'm getting ahead of myself.
You'll note that there's no data storage indicated in the test code. I'm adding some data to my Toggle object in code; in a real application I'll be pulling this information from some kind of data store. But I don't care about a data store at this point - that's an implementation detail. All I really want to focus on is the cleanest, most high-level way to use the logic.
Already I'm making some design decisions. I've decided that I'm going to identify each feature by a unique string. I've also decided that features will be disabled by default, which brings up another question: Do I really want all features disabled by default?
It's more likely that as time goes by, features that were once implemented for a few (e.g. beta testers) will be implemented for all. So I probably want to have the option of enabling individual features by default.
I just mentioned implementing features for users, so I'd better have some test code as well:
In systems with only a handful of users, having user level security is probably enough. But as the number of users grows, assigning privileges to individual users quickly becomes cumbersome, which is why security schemes typically implement the concept of a group. You assign permissions to groups, so that when you associate a user with a group they have the rights assigned to the group. Here's my initial test code for groups:
This group thing has me wondering, though. What happens if I have one group that denies permission to a feature, and another group that grants permission to a feature, and the user is a member of both groups? Which has precedence: denial or permission? I think I already have enough on my plate to get started coding, but I don't want to lose sight of this task, so I'm going to stub out another test and have it fail because it's incomplete:
All I have now is a bunch of test code that won't even compile yet. The next step: write a class with stub methods so the code can at least compile.
You can download the app below. You'll also need the ClarionTest template chain which is included in the ClarionMag Library on GitHub.