Merge lp://staging/~nahiljain/to-drizzle/ver-1.0 into lp://staging/to-drizzle
Proposed by
neh
Status: | Merged |
---|---|
Merge reported by: | Jay Pipes |
Merged at revision: | not available |
Proposed branch: | lp://staging/~nahiljain/to-drizzle/ver-1.0 |
Merge into: | lp://staging/to-drizzle |
Diff against target: |
403 lines (+373/-1) 5 files modified
.bzrignore (+2/-0) README (+1/-1) movetodrizzle/helpers/our_lexer.py (+155/-0) movetodrizzle/helpers/yacc_ver3.py (+90/-0) tests/helper_lexer_test.py (+125/-0) |
To merge this branch: | bzr merge lp://staging/~nahiljain/to-drizzle/ver-1.0 |
Related bugs: | |
Related blueprints: |
Upload a skeleton Cemented project with "stubs"
(Essential)
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jay Pipes | Needs Fixing | ||
Review via email: mp+26951@code.staging.launchpad.net |
Description of the change
Added test cases for create schema. These test cases are those statements which are valid and don't throw any error.
To post a comment you must log in.
Hi!
OK, good work so far, Nahil! Here's some stuff to work on. I'll place the merge proposal back in Work In Progress. When you correct the things below, simply switch the merge proposal back to Needs Code Review status.
1)
You need to tell BZR to ignore certain files that PLY generates. To do so, you must remove these files from BZR and then use the bzr ignore command, like so:
$> bzr remove --force helpers/parser.out helpers/parsetab.py
$> bzr ignore parser.out parsetab.py
2)
Let's change from using commands. getstatusoutput () to direct calls to the Lexer in our test cases for the lexer.py. I'd like you to start thinking more about making the stuff in lexer.py into distinct functions that may be called from other files. In other words, don't have anything in lexer.py print to stdout. Instead, have functions return sequences of things that can be iterated over.
For example, instead of this code in lexer.py:
117 +# Test it out
118 +#data = '''
119 +#CREATE DATABASE abc;
120 +#CREATE SCHEMA `neh`;
121 +#create TABLE first;
122 +#'''
123 +if __name__ == '__main__':
124 + data=sys.argv[1]
125 +# Give the lexer some input
126 + lexer.input(data)
127 +
128 +# Tokenize
129 + while True:
130 + tok = lexer.token()
131 + if not tok: break # No more input
132 + print tok
it would be better to have the following:
def tokenize(subject): input(subject) append( t)
"""Given a string subject, tokenizes the string into LexToken objects and returns them"""
lexer.
results= []
while True:
t= lex.token()
if not t:
break
results.
return results
Then, in your test cases, you can replace this code:
491 +import unittest ctions( unittest. TestCase) : output( self, sql): getstatusoutput ("python ../movetodrizzl e/helpers/ lexer.py '''%s'''" % sql) schema_ 1(self) : results= '''LexToken( CREATE, 'CREATE' ,1,0) SCHEMA, 'SCHEMA' ,1,7) IDENTIFIER, 'test', 1,14) SEMICOLON, ';',1,18) ''' debug_output( sql) ls(results, expected_ results)
492 +import os
493 +import commands
494 +class TestSequenceFun
495 + def lexer_debug_
496 + (res, output)= commands.
497 + return output
498 + def test_create_
499 + sql = "CREATE SCHEMA test;"
500 + expected_
501 +LexToken(
502 +LexToken(
503 +LexToken(
504 + results= self.lexer_
505 + self.assertEqua
with the following:
import unittest
import os
from helpers.lexer import tokenize
from ply import LexToken
class TestCreateSchem a(unittest. TestCase) : schema_ 1(self) : results= [ CREATE, 'CREATE' ,1,0) SCHEMA, 'SCHEMA' ,1,7) IDENTIFIER, 'test', 1,14) SEMICOLON, ';',1,18) assertEquals( results, expected_results)
def test_create_
sql= "CREATE SCHEMA test;"
expected_
LexToken(
LexToken(
LexToken(
LexToken(
]
results= tokenize(sql)
self.
That way, you are calling the lexer.py's tokenize function directly and not having to go through the shell just to test these things. Let's reserve using commands. getstatusoutput () to testing other things related to the overall program execution. For things like this, it's better to call the library functions themselves.
3)
I'd like you to start thinking more about consistency and modularity. If you see yourself repeating chunks of code, move a chu...