![SUnit ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (9)
Similar a Just in Time Resourcing
Similar a Just in Time Resourcing (20)
Más de ESUG
Más de ESUG (20)
Último
Último (20)
Just in Time Resourcing
- 1. ESUG – 1sep2009 - 0 Just-in-time Resourcing: fast tests in SUnit 3.2 and friends Niall Ross, Cincom 1 September 2009 Version 1.0 SUnit
Notas del editor
- 0 "Just-in-time resourcing: fast, flexible testing with SUnit and friends", Niall Ross, Cincom In the beginning was basic SUnit: just 3 classes. Then a fourth, TestResource, was added, for use when your tests became slow. However TestResource could create problems of its own and how to use it was not always clear. Switching code from test to resource was not as easy as it could have been. Niall will present the robust SUnit 3.2 implementation of resources, with examples. The talk will also cover some other SUnit topics - Basic SUnit did not handle tests that spawned subthreads. Niall will briefly reprise his StS talk on the SUnit add-on that handles this - SUnit tools and variants have appeared: Niall will look at some VW and VA tools, and how to combine using them with using basic SUnit.
- Once upon a time there was Ward Cunningham. When he pair-programmed with people, they were much more productive. Then there was Kent Beck – who wondered why this was. Then there were three classes – and a papar – and a name: Sunit And then the millenium came and suddenly there were four classes. Actually, it wasn’t very sudden.
- TestResource exists because test-driven development is only fast if your tests are fast. TestResource was deployed – and (rather later) explanations of how to use it were deployed. It was never a tricky pattern - it was in many ways a straightforward implementation of the singleton pattern, but it was just complex enough that people needed hints. Whereas some such implementations use a #defaultInstance or #current or whatever accessor and have users manipulate the singleton instance, TestResource>>current was mostly just expected to be called by the framework, while users simply referenced their TestResource subclasses, not those subclasses’ instances. This made a fair amount of sense – the intent I believe was to give users an easy and at the same time very safe (i.e. Minimal) interface – but the original Sunit Camp Smalltalk progenitors Jeff O’Dell and Joseph Pelrine and Sames were not in perfect unison on the point. In my refactoring of TestResource, I have been greatly helped by the fact that a many people have written ‘bad’ TestResource code – code that violates the pattern, that does things in bizarre and inefficient ways, etc., etc. When refactoring tests in a hurry, it was easy to guess wrong.
- One resource fails => nothing in suite runs. “ Do it later / You won’t need it” is an XP maxim, but every resource that any test in a suite needs is set up on starting, before any test is run. That might just be a point of style but the following is really annoying: - You finish work for the day. Last thing, you hit the overall run of 15,000 tests or whatever and go home. TestResources are by definition slow so their set up has not finished when you leave. Next morning, you gather that one resource failed and nothing was done. :-/ Make it fast last => refactor to resource but resource DNU self assert Competing resources: my system can connect to one database at a time, my tests run against specific databases, my overall suite wants to run all my tests, my database connections are test resources.
- Competing resources: my system can connect to one database at a time, my tests run against specific databases, my overall suite wants to run all my tests, my database connections are test resources.
- The original status was that a resource was set up once for the whole run, the best case scenario for performance but the worst case scenario for possible interaction between tests. In Sunit 3.2, this remains the default choice. If the coder makes their test reset a resource in some circumstance, they are choosing to sacrifice some performance in exchange for isolating other tests from theirs.
- The code that setUp all resources before the run starts, failing (and leaving the earlier ones setUp) if any could not be, is dropped . Instead, we add code so that each test asks whether its resources are available; as we shall see, this check is cost-free unless it is the first time of asking. As you can see from the deleted code, it used to be that only if all TestResources were set up would any of them be torn down. In 3.2, a resource that completes its own setUp and is available will be torn down even if another resource fails. This is still les rigorous than for tests: if a test enters setUp it will be torn down. Should we do the same for resources?
- The three-valued logic is that current is - nil : no setUp attempt has yet been made in this run - false : a setUp attempt was made but failed - an instance of the resource : a setUp attempt was made and succeeded
- Once upon a time there was Ward Cunningham. When he pair-programmed with people, they were much more productive. Then there was Kent Beck – who wondered why this was. Then there were three classes – and a papar – and a name: Sunit And then the millenium came and suddenly there were four classes. Actually, it wasn’t very sudden.
- The original status was that a resource was set up once for the whole run, the best case scenario for performance but the worst case scenario for possible interaction between tests. In Sunit 3.2, this remains the default choice. If the coder makes their test reset a resource in some circumstance, they are choosing to sacrifice some performance in exchange for isolating other tests from theirs.
- 6 Other changes: - fixes to ensure running single tests and debugging also calls resources. Put should:/shouldnt: into #deprecated protocol TestResource>>uninitialize / tearDown partners RestResource>>initialize / setUp More details package, class and method comments Things we did not change If a test enters setUp it wll be torn down. If a resource exits setUp and isAvailable, it will be torn down. Usd to be, if a resource failed, NIALL: MAKE CHANGE: - sunitVersion must return 3.2 not 3.1.1
- The original status was that a resource was set up once for the whole run, the best case scenario for performance but the worst case scenario for possible interaction between tests. In Sunit 3.2, this remains the default choice. If the coder makes their test reset a resource in some circumstance, they are choosing to sacrifice some performance in exchange for isolating other tests from theirs.