DOC PREVIEW
CMU CS 15441 - Design & Testing: Part Yin and Yang

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Design & Testing:Part Yin and YangComputer Networks (15-441) Fall 2007Daniel SpangenbergerDesign: Outside the Box•Two types of applications•Data-centric•What type of data and what does it look like?•Where do we store it•Protocol-centric•How do I talk to the world?•Mostly about interfacesDesign: Inside the Box•How do I access my data?•Interfaces!•How do I store my data?•Implementation!•Interfaces alleviate implementation pain•Wrap a good interface around an implementationLessons to Be LearnedLesson One•Don’t Repeat Yourself (DRY principle)•How much copy and paste do you use?•Put it in a separate function!•Design a small set of orthogonal interfaces to your modules•Adhere to them!Lessons to Be LearnedLesson Two•It’s OK for code to be shy•It’s preferred! (unlike for you)•Shy code...•Doesn’t expose itself in public•Doesn’t stare at others’ privates•Surely doesn’t touch others’ privates!•Doesn’t have a whole lot of friendsLessons to Be LearnedShyness (Example One)Which is better?int send_msg_to_user(int user_id,user_sock, char* msg);int send_msg_to_user(struct user_t*, char* msg);Lessons to Be LearnedShyness (Example Two)int send_to_user(char *uname, char* msg) {struct user *u;for (u = userlist; u; u = u->next) {if (!strcmp(u->uname, uname))...Consider factoring this into a separate function:void find_user(struct user *u, char* uname)Lessons to Be LearnedLesson Three•Keep it simple•No premature optimization•Even in the optimization contest, optimization generally not too important...•Throw out unnecessary features / requests•Not so important in 441...Lessons to Be LearnedLesson Four•Be Consistent•Naming•Style•Doesn’t matter what you choose, but choose something (no memcpy vs bcopy)•Decide and document memory ownership•Make it explicit in interfaces!A Note:Error Handling•Detect at the low level•malloc() returns null!•Report at high level•Not a good idea to abort()•Print an error message and attempt to continue...The Testing Mindset•Think like the adversary (like security!)•Your goal is breaking the code•If you can’t, you probably haven’t tried hard enough•This ensures that in five days you won’t spend five hours tracking down that bug...•Think about your code•Then write tests to exercise it•Hit the corners!Testability•Test at all levels!•From the user’s perspective•From the code’s perspective•Bugs are easiest to find in a local scope•Unit test things if possible•Make granular integration tests!Testing Methods•Unit•Integration•Regression •PerformanceUnit Tests•Tests specific features in a vacuum•Generally reserved for internals...•Hash tables...•Linked lists...•Read/write buffers...•Always in the language of the product•Use CUnit for 441 projectsIntegration Tests•“Do multiple pieces fit together?”•Tests a major user-facing feature•Does JOIN work?•Does PRIVMSG work with nine targets?•Generally utilizes a tool outside the product•We will provide you with some samplesBlackbox vs Whitebox•Blackbox•Implementation-agnostic test cases•Typical end-user use cases•Whitebox•Implementation-aware test cases•Mainly for the corner cases/implementation detailsRegression Tests•Shows how a commit affects the product•General idea:•Record what tests passed at rev N•See what tests pass at rev N+1•Look at the difference•If it wasn’t broken before you regressed•Could be reression on unit, integration, or performanceMore Regression•New features may uncover latent bugs•Write new test cases when found!•Make sure the test does what you think it doesPerformance Testing•General principle: Kick the shit out of it•Two approaches:•Isolate subsystems for analysis•Test the gamut for the big picture•Regression testing is valid for performance too!•Make sure you don’t make performance worse at commit•aWant more?•Joel Spolsky will give you some info (if you can take him!) www.joelonsoftware.com•There is the ACE framework http://www.cs.wustl.edu/~schmidt/patterns-ace.html•Presentation on patterns for network


View Full Document

CMU CS 15441 - Design & Testing: Part Yin and Yang

Documents in this Course
lecture

lecture

34 pages

lecture

lecture

38 pages

lecture

lecture

18 pages

lecture

lecture

28 pages

lecture

lecture

11 pages

Lecture

Lecture

64 pages

lecture

lecture

10 pages

lecture

lecture

19 pages

Lecture 6

Lecture 6

43 pages

Exam

Exam

14 pages

lecture

lecture

38 pages

Debugging

Debugging

23 pages

lecture

lecture

60 pages

review

review

27 pages

lecture

lecture

12 pages

The Web

The Web

28 pages

Lecture

Lecture

40 pages

lecture

lecture

42 pages

lecture

lecture

9 pages

lecture

lecture

10 pages

lecture

lecture

49 pages

lecture

lecture

26 pages

Project

Project

5 pages

lecture

lecture

40 pages

lecture

lecture

9 pages

lecture

lecture

41 pages

lecture

lecture

32 pages

lecture

lecture

36 pages

lecture

lecture

34 pages

lecture

lecture

45 pages

lecture

lecture

26 pages

lecture

lecture

6 pages

lecture

lecture

51 pages

Project

Project

16 pages

lecture

lecture

44 pages

lecture

lecture

13 pages

lecture

lecture

42 pages

lecture

lecture

36 pages

Project

Project

13 pages

Project

Project

33 pages

lecture

lecture

43 pages

lecture

lecture

49 pages

Load more
Download Design & Testing: Part Yin and Yang
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Design & Testing: Part Yin and Yang and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Design & Testing: Part Yin and Yang 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?