Following on from the second post in this series, a lexer has now been created that can tokenize some input for a hypothetical language. Given what was accomplished, theoretically I can use my language to create the most minimal sort of class definition. I’d really love to know if I’m completely on the wrong track here. So I’d like to get started on the parser at this point rather than fleshing out the language more.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
Build Your Own Language, Part 2
Following on from the first post in this series, I did a development spike that proved to myself I had some clue as to what I was doing. So now I want to get into actually building a language from soup to nuts: meaning I want an interpreted language that executes via a runtime. Granted, this will be a very simple language (and not very unique). It will also be a very simple runtime. Let’s see what happens, shall we?
Build Your Own Language, Part 1
In previous posts I talked about how one of my goals was to come up with an alternative to Gherkin. This is not in the “just to see if I can” category but rather because I believe it could be useful to roll your own Gherkin-like language. This post, however, will be in the “just to see if I can” category. Here I want to take what I learned about lexing and parsing and apply that to creating a simple programming language. Fair warning: I have no idea how this is going to turn out.
Testers Are More Than Their Skills
As a tester, you don’t just gather and manage test data. You don’t just create test cases. As part of quality assurance, you don’t just check requirements. You don’t just do reviews. In short: you are not just a bundle of skills. Rather, you are a personality and a mindset that happens to have a bundle of skills. So let’s talk about that.
Testing That is Effective, Efficient, and Elegant
There is notion in quality assurance and testing between verification and validation. Verification asks “Are we building the product right?” Validation asks “Are we building the right product?” Some people use this very distinction to draw a line between the activities of quality assurance and the activities of testing.
Continue reading Testing That is Effective, Efficient, and Elegant
A Tester Learns Rex and Racc, Part 3
This post continues on directly from the second post in this series. Assuming you’ve been following along, you’ve broken your input into a stream of tokens. Now you need some way to recognize higher-level patterns. This is where Racc comes in: Racc lets you describe what you want to do with those tokens. That’s what I’ll be covering here: how the parser works with the lexer.
A Tester Learns Rex and Racc, Part 2
In my previous post on this subject I started off on the learning process for building a lexer with the Rex (Rexical) tool. Here I want to update the logic I provided in that post to show how to make it more testable. I then want to expand on the example of using Rex with something a bit more substantive.
A Tester Learns Rex and Racc, Part 1
As a tester, I like to know how things work. So when I started investigating the basis for the tool Cucumber, I came across the concept of Gherkin. That was written with the help of a system call Ragel. What I was curious about was whether I could build one of these languages on my own, perhaps for a customized testing tool. This caused me to stumble upon Rex and Racc, which are two Ruby-based tools that help you build your own languages. The documentation on these tools, however, is on the bad side of awful. This post is purely to document and share what I learned.
Seeing and Thinking Differently
In talking about test teams as inventors, I mentioned that Albert Szent-Gyorgyi said “Discovery consists of looking at the same thing as everyone else does and thinking something different.” I wanted to go back to that thought because it’s not the act of “thinking something different” but rather the act of “thinking differently” that really matters to me. This is even more so the case in an industry where testing and development continue to move closer together and, in fact, often merge.
Effective Tests, Not Positive and Negative Tests
My opinion is that the “positive” and “negative” distinctions for tests are a faulty conceptual distinction. To me, only “old school” testers talk about “positive testing” and “negative testing.” Pretty bluntly stated, huh? I feel strongly about this because the way the terms are promoted, they take focus away from how a tester should be thinking about testing. That’s my belief anyway. I’ll try to defend that.
Continue reading Effective Tests, Not Positive and Negative Tests
Testers Write Tools — Like Test Libraries!
I keep looking for ways to get junior testers up to speed on writing test frameworks and test libraries. It’s a very good skill to have and it’s one that’s in demand. Beyond that, I think it paves the way for helping testing to evolve into what it must become: a group of practitioners that are test solution developers. As such, I’ve been using my Symbiont library for this purpose.
There Is No “Test Phase”
When people talk about the “testing phase” of a project, you already have a problem because that implies testing is an activity that is relegated to a certain phase as opposed to a structural element of the entire project itself.
Specifying Application Workflow Activities
Lately I’ve been writing a lot of specifications and by that I mean test specifications. And by that I mean the specifications you tend to write in tools like Cucumber, SpecFlow, Lettuce and so on. What’s been interesting is deciding at what level of intent to write at.
Symbiont Generators and Web Objects
Symbiont is a little further along, enough so that it makes sense to look at the basic idea of what it means to provide a façade over two tools. The focus here is really just to show you some tool construction from the ground up. This may help you understand tools like page-object or watir-page-helper a little bit or they may spur on your own creative efforts as you build your own tools.
Evolving the Symbiont
In my previous post about the start of my Symbiont project, I gave a few examples of what I can do now with libraries like Selenium and Watir. It probably wasn’t entirely clear what direction Symbiont was going to go, given what I described there. Here I’ll to provide a bit more of a roadmap for what Symbiont will need to accomplish.
Rise of the Symbiont
Lately I have been developing lots of test solutions, most of them having to do with automated testing. I originally developed a library that I called Lucid. This was in turn based on a library I was originally calling Terminus. Now I’m trying to distill a lot of what have learned into a library that I’m calling Symbiont.
I’ll be perfectly honest: what I’m writing here is largely for my own benefit as I get my thoughts in order, but I do have hopes for Symbiont to be something useful. So I will document its development path here and if someone besides me finds anything of interest in it, that’s great.
Tests as Specifications
In Testing’s Brave New World, I ended up talking about BDD and the concepts that testing, acting as a design activity, has to work within. That was a post fairly heavy on nomenclature concerns. I sort of skirted around the issue that it’s the tools we use in our BDD type activities that are often forcing us to consider this terminology. Even if you are not using a specific tool, but rather a technique like spec workshops — which is a “BDD activity” — you are still wrestling with these terms.
So let’s put this in some context.
Test Writers Step in Early
In my last post about what tests are for I talked a bit about the ability of test writers to be nimble in terms of getting quality-focused information — usually as a result collaborative discussions — encoded into readable tests that focus on intent rather than implementation. All of that’s easy to say but test writers sometimes have a hard time figuring out how to exactly do it in the context of the collaboration possibilities in their environment. Here I want to talk a little about the core ideas, backing them up with an example.
What Are Your Tests For?
A key question to ask is what you want to get out of your tests. I’ve already talked about how I think the purpose of testing is to find information and then communicate that information. That’s great and all … but … what do you actually want to get out of the tests themselves? The way you answer that question will shape your testing function to a large extent, particularly when it comes to picking supporting tools, such as for test management or test automation.
Test Teams Need Inventors: Balancing Creativity
In a previous post I talked about inventors as people who see and think differently. I also brought the idea of inventors having to institute cultural change in some cases. What I didn’t do is how an inventor utilizes their skill-set and mind-set to get that change going. So let’s talk about that. Hopefully I won’t make too much of a fool of myself.
Continue reading Test Teams Need Inventors: Balancing Creativity