The Inbox: KernelTests-ct.387.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: KernelTests-ct.387.mcz

commits-2
A new version of KernelTests was added to project The Inbox:
http://source.squeak.org/inbox/KernelTests-ct.387.mcz

==================== Summary ====================

Name: KernelTests-ct.387
Author: ct
Time: 24 October 2020, 12:40:40.526058 am
UUID: aa73c56f-88e1-3b4d-9d59-fb29df3363a7
Ancestors: KernelTests-ul.386

Adds regression test for Kernel-ct.1355 (source logging after SyntaxError). Should I invest further complexity into this test for the purpose of keeping the production source logs clean?

=============== Diff against KernelTests-ul.386 ===============

Item was added:
+ ----- Method: ClassDescriptionTest>>testLogSourceAfterReparseSyntaxError (in category 'testing') -----
+ testLogSourceAfterReparseSyntaxError
+
+ | class source |
+ SystemChangeNotifier uniqueInstance doSilently: [[
+ class := Object newSubclass.
+ source := 'foo [x'.
+ [class compile: source]
+ on: SyntaxErrorNotification do: [:error |
+ error resume: (source := source , ']')].
+ self assert: source equals: (class sourceCodeAt: #foo) asString.
+ ] ensure: [class removeFromSystem]].!

Item was changed:
+ ----- Method: ClassDescriptionTest>>testOrganization (in category 'testing') -----
- ----- Method: ClassDescriptionTest>>testOrganization (in category 'tests') -----
  testOrganization
 
  | aClassOrganizer |
  aClassOrganizer := ClassDescription organization.
  self assert: (aClassOrganizer isKindOf: ClassOrganizer).!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: KernelTests-ct.387.mcz

Jakob Reschke
commits-2 wrote
> Should I invest further complexity into this test for the purpose of
> keeping the production source logs clean?

I think keeping the logs clean is a worthy goal (especially if you have to
recover changes after not saving for a while).

Does your implementation still log anything? Since the test does not use
Monticello I think it should be silent. For extra emphasis you could have
used compileSilently: instead of compile:, though I thought muting the
SystemChangeNotifier would be sufficient here.

I tend to override performTest: to wrap the doSilently: around the test
method execution, if most of the tests in the class are exepected to log
something.



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html