Micro Object Testing

1. Micro Object Testing Presentation to ESUG 2003 Conference Andy Berry andy@tof.co.uk

2. 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

3. 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!

4. 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.

5. 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’

6. 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?

7. Where does MOT fit?

8. Models and Views

9. 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.

10. In Visualworks… Models are defined like this: Smalltalk.MicroObjectTesting defineClass: #Employee superclass: #{Core.Object} indexedType: #none private: false instanceVariableNames: 'payrollNo name address telephone ' classInstanceVariableNames: '' imports: '' category: 'MicroObjectTestingExamples'

11. Views are drawn in the UI Painter…

12. 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

13. 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]

14. 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

15. 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!

16. It shows two of the twelve MOT Principles… Construct example objects for objects that hold data. And: Ensure that running the tests is straightforward. Where possible, include the actual line of code needed to run the test.

17. 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

18. This shows another two MOT Principles… Test methods must run stand-alone and display results for testers. And: Build tests from the bottom-up.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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’

24. 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.

25. 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.

26. 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.

27. 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!

28. 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.

29. 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

30. Thanks for listening! • I hope you’ve enjoyed this presentation. • Please, try MOT! • If you need any further information, just contact me on: • andy@tof.co.uk