• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Micro Object Testing
 

Micro Object Testing

on

  • 424 views

Micro Object Testing

Micro Object Testing
(ESUG 2003, Bled)

Statistics

Views

Total Views
424
Views on SlideShare
424
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • In this presentation – given to the ESUG (European Smalltalk User Group) Smalltalk Conference in 2003 – Andy Berry explores some issues relating to software testing. The focus is on explaining the principles behind the Micro Object Testing (MOT) methodology.
  • This talk is about Micro Object Testing. (MOT) We’ll look at what MOT is, how it came about and the 12 MOT Principles and the benefits and costs of MOT. And, since a formal separation of Models from Views is essential to gain the benefits of MOT, we’ve included a brief review of how to do this.
  • I’ve been giving presentations to ESUG since about 1994 but this is the first one that includes any Smalltalk code. MOT is a practical, hands-on, topic so I’ve broken with tradition. But, a disclaimer is needed… “ The code is this presentation is included for the purposes of illustration only without any warranty as to its fitness for any purpose whatsoever.” In other words, don’t blame me if it’s full of bugs!
  • MOT is a practical approach to testing Object Oriented (OO) code. It’s part of a trend towards agile development methodologies like Extreme Programming (XP).
  • I’ve been developing Smalltalk (and the J-word) packages for many clients since 1988. I’ve always tried to include test code that other developers can use. Then, a few months ago, someone asked me to explain my approach. I wrote a paper. I had to call it something so I thought, what’s essential about this approach… I realised it was about ‘Objects’ and ‘Testing’ but the Micro was a bit less obvious.
  • But, the essential attribute of this approach is it’s simple, very simple. And, it doesn’t take much time to do it. And, you only add a small amount of code (probably, on average, no more than 3 short methods per class) to your software. And, as the slide says, ‘why not!’. At the time I came up with the name, an Internet search showed it was novel.
  • MOT fits into the agile development methodologies that say you should: ‘ Develop a bit, Test a bit, Deliver a bit’ in cycles within cycles. You shouldn’t regard MOT as a grand design, it’s merely my contribution to helping deliver the software that users want, and helping to make sure it works.
  • Now, we need a diversion into the land of models and views. There seem to be two types of developers… Some of us split our application into models and views and like the way that seems to structure our applications. Others don’t – they regard this as totally silly and can’t understand why we think it’s a good idea.
  • Well, my justification goes like this… Domain models should model the things your application is handling. So, for a payroll application, you’d have classes like Employee, Section, InlandRevenue (unfortunately!) and so on. Views display domain models and handle all the messy business of enabling and disabling buttons, allowing and disallowing changes and so on. As the slide says, I feel I’ve failed if changing a view requires changing a model. That’s not saying I always achieve it, but it’s a great feeling when I can do that.
  • Oh, no, it’s code! Yes, and it’s Visualworks (all the usual disclaimers and acknowledgements, of course). Those of you who don’t know the ‘VW speak’ will just have to forgive the next few slides. They’re only examples – you could achieve the same thing in your favourite dialect of Smalltalk just as easily, I’m sure.
  • Nearly every dialect has some form of tool to design your views. Here’s one I built in the UI Painter.
  • Now, this contains a subtle hint… Where do you think this code is? Is it in the view class or in the model class? The comment says ‘open a view on *this* object’. Yes, it’s an instance method of the model class. I maintain that’s where it should be. Some of you won’t agree, but, it’s my presentation! As the text says, you’ll need to add a model instance variable to your view class. Yes, I know that breaks encapsulation but this is the real world.
  • In Visualworks, you’ve got a concept of ‘adaptors’ that let you link parts on your view to aspects in the model object. This is one of these areas where there’s no standardisation across dialects. Nonetheless, they all have some way of letting you link your views to your models. If you want to explore MOT, you’ll need to find the method your dialect uses.
  • Now, lets look at a typical MOT method. This one is a class method of the Employee class and it does exactly what it says. If you call it, you get a populated instance of an Employee.
  • As the slide says, the line of code: “ Employee exampleObject “ Is a comment with a purpose. If you select the code inside it, and inspect the result, you’ll open an inspector on a populated example of an Employee object. Just imagine what you can do with that…
  • I said I was going to cover the ‘MOT Principles’. There are twelve (I’ll show you all 12 in a few slides time) but the exampleObject method is a good example of two of them. Any class whose instances hold data should include methods that answer example objects. Now, in this simple case, we could populate the instance variables ourselves but sometimes I use database rows, BOSS files and a whole raft of other approaches. To the tester, who may or may not be you, that doesn’t matter. They have a way of getting hold of an example of the object. Quite often, I create a simple example object to start with and then add others as I find out more about the object. The “ Employee exampleObject “ comment allows you to know what to do without having to figure it out or even type anything. ‘Just select and run’ should be your MOTto! (Sorry, couldn’t resist the pun!)
  • Now, let’s look at how we’d test our view. Well, we’ve just built a populated instance of an Employee, so we’ll use that. And, we’ve equipped our Employee object with a way of opening a view on itself, so we’ll use that as well. When we select and run the code in the “ Employee basicTest “ comment, what happens? A view is opened on our example Employee object. Very simple but very powerful. OK, the Employee view may be boring, but when you can test complex view this simply, MOT starts to pay dividends. If you have more than one example object, then you can just add matching test methods.
  • The example on the previous slide shows two more MOT Principles… Every test method should run, just out of the box, with no long list of ‘you must does’. The way that this method exploits our earlier effort, re-using the example object, is important. If you build your test methods from the lowest level to the highest level, you’ll be able to write methods like: basicTest “ perform a basic functional test of the Payroll system” “ PayrollSystem basicTest “ | system | system := PayrollSystem exampleObject. system openView. When you run that, and it works first time, the sense of achievement is amazing!
  • So, here’s the first of the MOT Principles…
  • And, here’s some more. The one on infrastructure code is actually rather broader than just infrastructure. What it’s trying to say is - get the things that have the widest implications working first.
  • The point about testing after changes is that you must think carefully when deciding what to test after making a change. For example, removing the telephone number from the Employee object could affect the behaviour of the object required by the Section object. In practice, this doesn’t seem too difficult and your tests should be sufficiently simple so you can run them anyway, just to be sure.
  • We’ll come back to the ‘knowledge base’ idea in the next slide. I have a simple way of tracking things I must do. I use a Workspace page for low-level tasks. Simple, cheap and it seems to work.
  • One of the MOT Principles says: “ Always bear in mind that the tests form an essential knowledge base about your application.” This is partly an appeal to make your tests understandable. Any developer running a test should be able to see what it’s testing. But, it’s more than that… The sum of your tests should cover all of the system and provide a way of sharing knowledge. This is one of those things that you must experience to appreciate.
  • In this case, I’ve pointed a fellow developer at a particular test method that gives him an overview of the Employee object. If he needs database code, he then looks for examples amongst the other example methods. Even if he doesn’t find one, he should consider writing one himself to share what he finds out with others.
  • No, I’m not boasting! But, it does surprise me how often things work first thing. It’s a great feeling! The key reason is, as I say, because MOT seems to encourage you to base things on firm, tested, foundations.
  • Now, I know, some ‘managers’ will say: ‘That’s a lot of time to spend developing code that we’re not going to deliver’. My response is: ‘But you are delivering it. The support team can use it and so can all the developers who work on the application after I’ve left to do something else.’ And, clients are quite happy when software works, as I’m sure one or two of you know!
  • If I’ve sold you MOT, you’re probably thinking ‘interesting, but I’m right in the middle of a project, how can I use it?’ This slide gives you some ideas… Don’t forget the ‘Micro’ in MOT. Start small and just do it!
  • I’ll put a version of this presentation on the Web at the URL given on the slide. I’ll also put a copy of the paper I wrote. This covers the same information but it may be easier to follow than the presentation.
  • We’ve covered: What MOT is The model/view approach to OO development The twelve MOT Principles Benefits and Costs of MOT Where to find out more
  • I hope you’ve enjoyed this presentation. As you can gather, I think I’ve got something interesting in MOT. I hope you do as well and I look forward to hearing how you get on using it in your own projects. Thanks for listening!

Micro Object Testing Micro Object Testing Presentation Transcript

  • Micro Object Testing Presentation to ESUG 2003 Conference Andy Berry [email_address]
  • What We’ll Talk About
    • What is MOT?
    • How did it come about?
    • Models and Views
    • The MOT Principles
    • The Benefits and Costs of MOT
  • But, First, An Amusing Fact…
    • In previous presentations to ESUG, I’ve never included any Smalltalk code!
    • But, MOT is practical.
    • So, there’s some code!
    • It may not be perfect, it may not be pretty, but…
    • It seems to work!
  • What is MOT?
    • MOT is a practical approach to testing OO code.
    • It’s part of a trend towards more ‘agile’ development methodologies like XP.
  • How did MOT come about?
    • I’ve been using MOT informally for many years and over several projects.
    • But, I was recently asked to explain my approach to testing…
    • I wrote a paper and it needed a snappy title, so…
    • I called it ‘Micro Object Testing’
  • Why ‘Micro’?
    • Because it’s very simple!
    • Because it doesn’t take much effort.
    • Because you only need a small amount of test code.
    • And, anyway, why not?
  • Where does MOT fit?
  • Models and Views
  • Why separate them?
    • Your model objects make up the ‘domain model’ that models the things you’re trying to handle.
    • Your views are messy and handle all the nasties involved in dealing with those horrible people – the users.
    • I honestly feel I’ve failed if I can’t switch views without altering my models.
  • In Visualworks… Smalltalk.MicroObjectTesting defineClass: #Employee superclass: #{Core.Object} indexedType: #none private: false instanceVariableNames: 'payrollNo name address telephone ' classInstanceVariableNames: '' imports: '' category: 'MicroObjectTestingExamples' Models are defined like this:
  • Views are drawn in the UI Painter…
  • You open Views by… openView "open a view on this object"   | view |   view := EmployeeView new. view model: self; open For this to work, the view must have an instance variable called model
  • And Views are linked to Models with ‘Adaptors‘ address "answers aspect adaptor for the address field"   ^address isNil ifTrue: [address := AspectAdaptor subject: self model. address forAspect: #address; subjectSendsUpdates: true. address] ifFalse: [address]
  • You’d build an Example Object like… exampleObject "answer an example of an Employee object"   " Employee exampleObject "   ^self new payrollNo: '374'; name: 'Fred Smith'; address: '12 Some Street, Somewhere'; telephone: '0111 222 333' As a class method in the Employee class
  • Did you notice?
    • I slipped in a somewhat unusual comment:
    • “ Employee exampleObject “
    • If you select this and inspect the result, what happens?
    • Well, if I’ve coded it correctly, you see an example of an Employee object…
    • Very simple, but very, very useful!
  • It shows two of the twelve MOT Principles… Ensure that running the tests is straightforward. Where possible, include the actual line of code needed to run the test. Construct example objects for objects that hold data. And:
  • You’d run a Test with… basicTest "perform a basic functional test"   " Employee basicTest "   | employee |   employee := self exampleObject. employee openView As another class method in the Employee class
  • This shows another two MOT Principles… Test methods must run stand-alone and display results for testers. Build tests from the bottom-up. And:
  • So, what are the MOT Principles?
    • Test frequently – every few minutes or as soon as you’ve completed a testable chunk of code.
    • Test the domain objects, not the views.
    • Construct example objects for objects that hold data.
    • Test methods must run stand-alone and display results for testers.
  • And…
    • Build tests from the bottom-up.
    • Test infrastructure code first, then application specific code.
    • Re-use as much test code as you can.
    • Keep the tests as simple as possible.
  • And, we’re over half way…
    • Ensure that running the tests is straightforward. Where possible, include the actual line of code needed to run the test.
    • Whenever you change code, always re-run the test for the code you’ve changed. If the changes affects the behaviour of the object, you may need to re-run higher level tests as well.
  • And, the last two…
    • Always bear in mind that the tests form an essential knowledge base about your application.
    • Make corrections as soon as you can. If you find an error you can’t correct immediately, write it down so you won’t forget it.
  • What’s this ‘Knowledge Base’ idea?
    • Let me illustrate with a example…
    • Other developer: ‘Andy, what behaviour does a Employee have?’
    • Me: ‘Well, if you look at the basicTest method, you’ll see’
  • He learns…
    • The EmployeeView (opened by the test method) shows him what data an Employee has.
    • He then looks at the Employee class again and finds a databaseTest method that shows how to load and save an Employee object.
  • The Benefits of MOT
    • Now, I’m not claiming that I’m anything special…
    • BUT…
    • It amazes me how often parts of applications I develop using MOT work first time I run them.
    • That’s simply because they are based on firm foundations.
  • The Cost of MOT
    • I probably spend about 20% of my time developing test methods.
    • It seems a lot, but I’m sure the benefits in terms of client (and, job) satisfaction makes it worthwhile.
  • Introducing MOT on your project…
    • Why not just start developing low-level test methods?
    • If you add comments to them so it’s obvious how to run them and encourage other developers to regard them as a source of example code, you’ve done it!
  • Further Information
    • This presentation will be available on
      • www.tof.co.uk/mot
    • There’ll also be a copy of the ‘Micro Object Testing’ paper on the same site.
  • What we’ve covered…
    • What is MOT?
    • The model/view approach to OO development
    • The twelve MOT Principles
    • Benefits and Costs of MOT
    • Where to find out more
  • Thanks for listening!
    • I hope you’ve enjoyed this presentation.
    • Please, try MOT!
    • If you need any further information, just contact me on:
      • [email_address]