Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

3

One of the hardest piece of knowledge to learn as a developer is: code duplication does not mean responsibility duplication. Having said this, you are testing different methods so it's ok to have more than one test. In this case, you are testing complementary (or were they supplementary? I never remember it) methods, so to test one, you need to have the ...


2

If you really want to unit test that logic, you should fake its data. In order to do that, you need a way to inject that dependency instead of getting it straight from it. You have 3 options: Installing a framework to mock the import (as detailed in https://medium.com/@emandm/import-mocking-with-typescript-3224804bb614) Have a constructor that is ...


1

If you are using any I/O (in this case, local storage), you must have fallen into an integration test. A unit test could be that when logout is executed, the call to clearing the local storage is made (using an spy on localStorage). An integration test could be that you have data in the local storage and after you have logged out, you don't.


22

None of your QUEUE_* functions validate their input arguments before using them. NULL pointers will be a problem, particularly for the pointer-to-pointer arguments. C's memory-allocation functions return a void*, which implicitly converts to any other pointer type. This means that you don't need to typecast the result of calloc. Doing so can actually ...


3

I think the test is ok. Remember what you're testing is this const signIn = ( username, password, successCallback, errorCallback, ) => { Auth.signIn(username, password) .then(user => successCallback(user)) .catch(err => errorCallback(err)); }; and NOT Auth. Here Auth is just a dependency so you will stub its functionality. ...


13

This looks really nice! Here we go: Is the API well thought and idiomatic? Mostly. For a library as simplistic as this, you probably want to avoid creating a special enum when returning NULL on error will suffice. For this you could make the QUEUE_initialize() function return a pointer to the queue_t instead of having a queue_t** passed as an argument. ...


4

Overall good job! Does the code looks "modern" (i.e. uses modern conventions etc)? One of the things I see regularly here on Code Review is the advice to allocate memory based on the size of what an object points to rather than the object type itself: *queue = calloc(1, sizeof(*queue)); and node_t* node = calloc(1, sizeof(*node)); This eases ...


9

When you have queued a pointer you can never get that pointer again. It is also very difficult to know when that pointer has been dequeued. This is a recipe for leaks. Instead returning the pointer itself instead of the data contained is a better idea. Or store the entire object wholesale.


2

Replace explicit recursion with library combinators. Unduplicate and inline as much as possible. testImpl :: Int -> (Bool, String) -> String testImpl i (cond, msg) = unwords $ [ if cond then "ok" else "not ok" , show i ] ++ case msg of [] -> []; m -> ["-", m] tests :: [(Bool, String)] -> IO () tests xs = do putStrLn $ unlines $ ...


Top 50 recent answers are included