Automated Testing Performed by Developers

I finished my thesis about a month ago and it was checked and graded just recently. Title of the thesis is “Automated Testing Performed by Developers”. It consists of a literary review that forms a theoretical basis for the action research. The thesis is available online.

I’m pretty happy how it turned out and I learned a lot while doing it. There are of course many things that I would want to fix, change or expand, but there is only a limited amount of time to write it. The thesis could be summed up as “testing fun, testing good, testing hard”.

Now I just have to finish one more course before graduating.

Targetting spells

My next goal was to start working with actual spell objects. I sketched my ideas on a paper and decided that there would be a single Spell class that could be parametrized to handle various spells. And the first step to creating that class would be targeting characters with spells.

I started writing following test:

    def test_target_single(self):
        """
        Targeting a single character should be possible
        """
        level = LevelBuilder().build()
        
        character = (CharacterBuilder()
                        .with_level(level)
                        .with_location((5, 5))
                        .build())

        spell_generator = SpellGeneratorBuilder().build()

        spell = spell_generator.create_spell(spell_name = 'healing wind', 
                                             target = character)

        assert_that(character, is_in(spell.target))

Nothing too complicated. My focus will be on healing wind spell and after I get it working, I can start from the beginning and see what needs to be changed to get magic missile working. You may notice that target attribute is a list of some sort, instead of just a single entity. I’m jumping forward a bit here, but I know already that I want spells that can target multiple characters and felt that it makes sense to write the system to support that from the beginning.

The code needed to make the test pass is simple:

class Spell():
    """
    Class to represent spells
    
    .. versionadded:: 0.9
    """
    
    def __init__(self):
        """
        Default constructor
        """
        self.target = []

class SpellGenerator():
    """
    Factory for creating spells
    
    .. versionadded:: 0.9
    """
    @logged
    def __init__(self):
        """
        Default constructor
        """
        pass
     
    @logged
    def create_spell(self, spell_name, target):
        """
        Create a spell
         
        :param spell_name: name of the spell
        :type spell_name: string
        :param target: target of the spell
        :type target: Character
        :returns: ready to use spell
        :rtype: Spell
        """
        new_spell = Spell()
        new_spell.target.append(target)
 
        return new_spell

SpellGenerator will be the most used interface for the spell subsystem. It can be used to create all the different spells.

Code for this can be found from commit 112e9a77654490e0c8875c23572aa561bf35462d

Small steps

I managed to figure out why the style sheets were not working on Herculeum. While Python 2.x was treating them as ASCII, Python 3.x is treating them as Unicode by default. And since the actual file is in ASCII, there was a mismatch that caused errors in serialization and in turn prevented them from loading.

Switch to Python 3.2 has caused other problems too and I have been slowly patching things back in order. Behave does not currently seem to generate xUnit reports without throwing an exception, so I had to exclude it from the test reporting. I’m probably either going to use regular text output or figure a workaround for the error. As far as I understand, the problems is related to Unicode vs. ASCII again.

But the important thing is that I’m making some progress again and fixing little bugs that are lurking in the code. Eventually I want to finish the curses interface and release 0.9 and then start working on the magic system. That probably means a new player class that relies mostly on the magic.

My thesis is nearing completion. If everything goes as planned, I’ll return it in two weeks. The review process takes around a month after that. I’m really looking forward seeing it in print too.

Even more reading

Since it’s 6 months until christmas and getting presents, I treated myself by getting some more interesting reading:

Growing Object-Oriented Software, Guided by Tests by Freeman and Pryce I have read before. However, I never owned the book, only borrowed it from a colleague, but because it is such an interesting book, I wanted to have my own copy. After I finish my thesis (or maybe even before that), I’m planning on taking that to sit on my office desk where rest of the team can borrow it.

How Google Tests Software by Whittaker, Arbon and Carollo sounded interesting and had gotten good reviews. Scale of the testing in such a huge company is probably something different from what I have learned to do and will most likely offer nice ideas and thoughts.

Domain-Specific Languages by Fowler and Parsons I ordered because of brief foray into DSL with my cutesy-platform (the one used in pyherc for behaviour driven testing).

So, the focus is on testing and things that can facilitate it. All this should be both interesting, useful and helpful for my thesis.

Writing project management plan

So, we had an assignment to write out project charter and plan schedule for it. Instead of writing just that, I expanded it to include initial drafts of the project management plan. By doing the actual plan early, I hope to get feedback from instructors and other stakeholders. Also, in my experience it is easier to fix something than write something completely new. By having some kind of plan in place, I can revise and fine-tune that in the future. And that will be easier than starting from a blank slate (which I learned while writing my bachelor’s thesis some years ago).

Thesis – further plans

The difference between Bachelor’s thesis and Master’s Thesis is that the latter one is much larger and has more theory included. This of course could pose a problem, if you want to do very concrete things (write this code, change that process) or the expectations of the host company are different. I don’t think this will be a problem though, as long as goals and focus are clearly communicated to stakeholders clearly and they accept them.

Research methods are going to play part in my thesis, so one one the first goals is to do some searching and try to get overall view what is available.

Hint: Design Science is an outcome based information technology research methodology, which offers specific guidelines for evaluation and iteration within research projects.

Things I should be paying close attention to:

  • Subject and approach
  • Defining the problem
  • Theoretical basis
  • Research method
  • Implementation
  • Results and conclusions

Informal data gathering

So, my thesis project is currently in initiation phase. I’m drafting ideas and defining rough scope of the project. One part of this phase is to define the problem more clearly and find some ideas how to solve it before really tackling it.

I quickly learned that it’s great idea to have notebook and pen with me always. Last Saturday we had contact lessons and I heard lots of good ideas during coffee breaks. Same thing happens at work, sometimes the coffee breaks are the most productive time of the day. As a result, I have several pages of hastily jotted down notes that might or might not come handy.

This is probably part of the idea behind kick off events that some projects have. People get to know each other, get in same page regarding the project and can throw ideas back and forth freely.