An error occurred fetching the project authors.
- 22 Oct, 2018 1 commit
-
-
Jérome Perrin authored
-
- 03 Nov, 2015 1 commit
-
-
Romain Courteaud authored
It's the easiest/laziest way to get correct test results
-
- 11 Mar, 2015 1 commit
-
-
Kirill Smelkov authored
This reverts commit 193f5cdd, reversing changes made to 4ee61a23. Jean-Paul suggested we first better further review our code review / merging procedures and use e.g. this particular merge request as a basis for that. Thus I'm reverting this merge, so people could study and re-merge it "properly". ~~~~ Please note: I could potentially rewrite master history so that there would be a no merge commit at all, as e.g. my branch was not so far ever merged at all. In contrast to draft branches, that is however a not good practice to rebase, and thus rewrite, master history - what has been committed is committed and we only continue. So later to re-merge my branch, if it will not be changed, we'll need to first revert this revert (see [1] for rationale), or alternatively I could re-prepare my patches with different sha1 ids and they will merge again the "usual way". [1] http://git-scm.com/docs/howto/revert-a-faulty-merge.html
-
- 03 Mar, 2015 1 commit
-
-
Kirill Smelkov authored
So far BigFile was not unit-tested and because of recent BigFile patches and fixes Romain suggested to write tests for it. We test: - working with BigFile via its public interface: * GET/PUT both in plain and with ranges variants, *.getData()/.getSize(), and * recently-introduced ._appendData() - that BigFile correctly handles situations where .data is either None or str or BTreeData and that migration automatically happens to BTreeData on append. ~~~~ Unlike common case, BigFile more directly works on REQUEST and RESPONSE (instead of plain object publishing), so to test it we need not only call methods and compare return values but first prepare proper request/response, set them up and analyze response headers and content after method invocation happened. For preparing request/response Zope provides utility Testing.makerequest() and its 2 variations but for our case they all turned out to be not flexible enough - e.g. Testing.makerequest() hardcodes request stdin=sys.stdin https://github.com/zopefoundation/Zope/blob/master/src/Testing/makerequest.py#L56 (and we need to provide it to e.g. upload via PUT), makerequest from Products.CMFCore.tests.test_CookieCrumbler hardcodes request environment http://svn.zope.org/Products.CMFCore/branches/2.2/Products/CMFCore/tests/test_CookieCrumbler.py?revision=126491&view=markup (and we need it for convenient way to set request headers), etc, so first we introduce our own makerequest-alike that 1. always redirects stdout to stringio, 2. stdin content can be specified and is processed, 3. returns actual request object (not wrapped portal). on top of that we introduce two convenience helpers GET and PUT to prepare same-named request and then a function to generally invoke a request on object and check results - i.e. given object and request, find appropriate method, call it appropriately, verify return value, http status code, response body and check asserted headers. All that in one line - to keep signal-to-noise ratio high. ~~~~ There are still some things to fix and improve: - Zope translates 308 http status code (which BigFile PUT with range query returns) to 500 because that code is experimental: https://github.com/zopefoundation/Zope/blob/master/src/ZPublisher/HTTPResponse.py#L226 https://github.com/zopefoundation/Zope/blob/master/src/ZPublisher/HTTPResponse.py#L64 - It is not clear (to me) what PUT range query should return for empty file. In HTTP/1.1 ranges are specified as both start and end inclusive so currently for empty-file case BigFile code returns "0--1" (= "0" - "-1") but that is not valid according to HTTP/1.1 spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 and again, judging from spec, it is not clear how to represent range "empty". For now I've left "0--1" checked as correct, but left a note in tests this is dubiously so. - Support for 'If-Range' and multiple ranges in 'Range' headers is not tested. - There are no scalability tests, i.e. "let's write a lot of data into BigFile and see how underlying BTreeData behaves" So all it is is basic tests so we know general BigFile logic and interface work. Test is done as a "live test" under erp5_big_file bt5 as per Sebastien suggestion. Helped-by:
Sebastien Robin <seb@nexedi.com>
-
- 12 Jan, 2015 3 commits
-
-
Sven Franck authored
-
Sven Franck authored
-
Sven Franck authored
-
- 02 Oct, 2014 1 commit
-
-
Romain Courteaud authored
-
- 18 Sep, 2014 1 commit
-
-
Romain Courteaud authored
-
- 05 Sep, 2014 1 commit
-
-
Julien Muchembled authored
-
- 10 Sep, 2013 1 commit
-
-
Arnaud Fontaine authored
-
- 31 Mar, 2011 1 commit
-
-
Rafael Monnerat authored
* Initial Release Due activity-race, the rules should be present before install erp5_demo_maxma_sample, because it contains simulation movements with workflows history. This case provokes the simulation be re-expanded and raising errors due missing (or not indexed) rules. git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@44845 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
- 28 Mar, 2011 1 commit
-
-
Rafael Monnerat authored
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@44696 20353a03-c40f-0410-a6d1-a30d3c3de9de
-